The Humane Programmer

By no means could I have missed the news that Microsoft has announced a new Operating System, this time a Cloud Operating System, named Azure. This comes in the context Richard Stallman telling that "cloud computing is a trap". To quote from the original article:

Cloud computing was simply a trap aimed at forcing more people to buy into locked, proprietary systems that would cost them more and more over time.

"One reason you should not use web applications to do your computing is that you lose control," he said. "It's just as bad as using a proprietary program. Do your own computing on your own computer with your copy of a freedom-respecting program. If you use a proprietary program or somebody else's web server, you're defenceless. You're putty in the hands of whoever developed that software."

One remark Stallman made becomes very interesting in the context of the wikipedia cloud computing description:

The interesting thing about cloud computing is that we've redefined cloud computing to include everything that we already do. Richard Stallman

Cloud computing is a general concept that incorporates software as a service (SaaS), Web 2.0 and other recent, well-known technology trends, in which the common theme is reliance on the Internet for satisfying the computing needs of the users. For example, Google Apps provides common business applications online that are accessed from a web browser, while the software and data are stored on the servers. Wikipedia

Let me pause this thread for a moment and talk to you about the other big problem on the internet today, copyright. If you haven't heard about the recent copyright technology craze, here are a few items:

Disney's release of its first Blu-Ray title, Sleeping Beauty, contains over one hundred and twenty pages of legalese when completely unspooled, including a 57 page EULA to access the BD-Live content and a 63 page privacy policy. Read more here

For software that appeals to a wide audience like EA's latest sim game Spore, it's sometimes the first time the average person gets a good taste of how digital rights management (DRM) puts the screw on legitimate users.

Spore's DRM limits customers to only three activations after the game is installed. That number isn't restored even if the game is uninstalled. Three is what you get unless you call up Electronic Arts customer support and give them your sob story.Read more here

Steve Jobs, Apple's chief executive, has confirmed there is a 'kill switch' built into the iPhone that allows Apple to remotely delete malicious or inappropriate applications stored on the device. Read more here

And one from the "cloud":

Google, I am a very lucky American who is living the dream of owning or being a partner in several small businesses. Each of these businesses utilize Google’s GMail and Google Docs, in an effort to cut down on infrastructure costs and keep an open stream of communication between all employees, contractors and clients.

Since Google has decided to take my account away from me, the nucleus of our company communications has been taken away and now is replaced by a black hole. My small business communications are now ruined until my account is reestablished.Read more here

So, to resume it:

• You don't own the media you bought
  
• You don't own the mobile device you bought
  
• Your data is in somebody else's hands - now Google, tomorrow Microsoft, then who knows
  

On the other hand:

• You can use software that you know exactly what it does
  
• You can use open protocols that you know exactly what they do
  
• You can use a device that uses this kind of software and protocols and operating system
  
• You can use software you own to create data that you own that's stored on the devices that you own
  
• You can choose to share, collaborate or give away for free your data on the internet if you wish to do so
  

Which list would you choose?

Which list do you think people will choose in the next few years?

What do you think this tells about them?

I think that too, but, on the other hand, I can't feel sorry for them.

As for myself, I do use google docs and yahoo mail, but I always keep a backup and I've never felt safe using them. They are useful, especially for collaboration, but I wouldn't use them for mission critical tasks. My connections, my business mail, my important documents are in places I can reach without going through google, microsoft or yahoo. Call me a paranoid, and I'll tell you that I'm an engineer and as such I think about failsafe mechanisms. As should you.

There are many more things to say about those topics; I think that the latest Felix' posts here and here bring other details in the story, as do many other internet links.

Until next time, keep it open, keep it safe!

---

Mosaic Works offers advice for choosing an outsourcing partner in Eastern Europe - FREE for the customer.

One of the most successful principles of engineering, including software development, is KISS = Keep It Simple, Stupid. (I sometimes think of it as Keep It Simple, (you) Stupid!). Here are a few of my personal experiences with this principle.

Last year, a few co-workers developing a ticketing project came to me asking for advice regarding a role, permission and resource based access control system. The presentation of the requirements took about 30 minutes, and I was still confused on some points. Therefore, I stopped the discussion after the requirements presentation, asking them if the customer knows how intricate and difficult it is to define such a system. I told them that no matter which bright hacker they would have as consultant, the effort required will be immense. I mean, its complexity was similar to the Windows implementation of permissions. My message was, basically, keep it simple.

Talking about Windows, does anyone really understand Windows permissions?



For example, can you tell me what “Special permissions” are about? Did you ever see the advanced permissions? What is “Write Extended Attributes”? Honestly, to me, it makes no sense. I've never passed the phase where you create some users, add them in a group and give full control to the group on specific resources. The whole thing is too complex, and it's not really useful for most users.

Contrast this with the Linux way:

Every file or folder in Linux has access permissions. There are three types of permissions (what allowed to do with a file):

• read access
  
• write access
  
• execute access
  

Permissions are defined for three types of users:

• the owner of the file
  
• the group that the owner belongs to
  
• other users
  

Thus, Linux file permissions are nine bits of information (3 types x 3 type of users), each of them may have just one of two values: allowed or denied.
Simply put, for each file it can be specified who can read or write from/to the file. For programs or scripts it also can be set if they are allowed to be executed.

(whole article here)

Not only you can read and understand it in 30 seconds, but you can also relate immediately to what it talks about. It's useful, it's usable, it works. You don't have to think about whether you should:

inherit from parent, reset permissions, or overwrite them.

Another example is what happened about a month ago. We were discussing the GUI for editing a number of items organized in a hierarchical structure. Trouble was, save and cancel actions had the potential to create strange side effects. You would open a popup dialog, edit something in it, save it and the question was if all the items needed saving at that point. If not, then the referential integrity was not preserved. If yes, you saved the items from a popup who was supposed to save only the thing you edited in it.
After throwing a few ideas, we realized that there's a simple way to solve it: automatically and always save everything in background, like Gmail, Makagiga and other modern applications. This not only solves the referential integrity problem, simplifies the logic of the application but also proved to have benefic side effects in the code. A perfect example of KISS.

Another example is Mantis. Mantis is an incredibly effective issue tracker system, both easy to use and full-featured. It also happens to have a few touches of genius.
The first thing that made me say that was the fact that the issue number in mantis is unique, no matter in which project it is contained. This means that you can discuss with your customer about issue no. 1234566 and go directly to it, without having to navigate through the 100 projects of your organization.
Another splendid idea is the presentation of issues reported by a person who left your team. In mantis, you still see the name of the person, but it is presented with strike through, like this: Alex. Simple and effective.

Certainly, simple solutions are the most difficult to find. You need to invest time, involvement and lots of brain power into it. You need to keep reading, seeing what others are doing, searching ideas and have the courage to use them. It may not look so smart when you implement it, but it will certainly raise a few eyebrows when it's ready... Or, if you're really good at it, you'll say in the end: "I was so stupid. How didn't I think of this before?"

---

For anyone who's interested, here's some additional reading about how to apply the KISS principle:

• Getting real, a free online book by the developers of Ruby on Rails, BaseCamp and other successful applications
  
• The Art of Unix Programming, chapter Basics of the Unix Philosophy, a free online book about sound design, a must read for any serious software developer. If you don't have time, read at least this page; it's an amazing resource
  
• The Humane Interface, a book about GUIs written by the man behind the MacOS interface, Jeff Raskin. It's not free, but you can find its summary online, along with many other essays by the same author.
  

---

Personal advertisement: I am PassionIT and I help teams develop high quality software. I train, I help improving and I work hands-on, depending on the needs. Contact me if you need help. Alexandru Bolboaca-Diaconu

---

 

I wrote before about the litterature of Arthur C. Clarke. I said then that I didn't think of him to be a good writer. However, I have the outmost admiration for him as a visionary and as an engineer.

As most people have probably found out already, Arthur C. Clarke died today. I am one of those who will regret it. In a sense, I've grown up with him, with his ideas and with the ideas that he inspired. Even though his books were not litterary interesting, they certainly were compelling from the engineer point of view.

I'm sure that, even though he died, we will still hear about him. I hope that the Arthur C. Clarke space elevator will soon see the light of day, along with many other of his ideas.

As an engineer, I'd like to learn from him how to imagine practical future solutions for complex problems. He was amazing in this aspect.

Mr. Clarke, I for one will always remember you, and will always be inspired by you. Rest in peace.

I have recently stressed the importance of having a team formed from very good developers in order to obtain software quality. I received interesting feedback regarding this statement, including one issue related to the ego of programmers.

The problem goes like this: you gather your best developers and ask them to work on a project. Instead of producing much more than the average programmers, they fight over design, libraries and principles.

I believe that there are a few key problems when this happens. First of all, design by committee has proved to be an anti-pattern. Second of all, because software development is about ideas, all projects should start with prototype implementations that are refined during the project's consequent phases. Third of all, there's the Ego Problem.

It is easy to see that developers often have an oversized Ego. That aspect can be very good or very bad for a project.

Let's take for example Linus Torvalds. Whenever he talks in public, he says "I'm always right, you're wrong. If I don't like what you say, I may say you're ugly and stupid". That's certainly an oversized ego.
On the other hand, nobody can say that Linux is not a succesful project. More than that, Linux is organized in such a way that Linus Torvalds doesn't control all its phases. And there's even more to the story: Linux might not have been so succesful if Linus Torvalds had a smaller ego.

I've also met the other type of developer. The one who thinks that knows everything, the one that doesn't agree with older and smarter people from the industry. The one who thinks his ideas are very bright when they actually are really bad mistakes. The one that tries to impose his solutions to everybody else.
I guess that this phenomenon takes place in Romania because the IT industry doesn't have tradition, doesn't have values, and it's not settled yet (actually, like the whole society). People still try to be original when they should just listen to the voice of the experience.

But what is different between Linus Torvalds and John Developer My-Solution-Is-Always-The-Best?
You can probably name a lot of differences. Knowledge and understanding are a few of them.

I believe that the main factor differentiating a Good Ego from a Bad Ego is the intellectual honesty.

If you read what Linus Torvalds says, you will see that he has no problem to point out his mistakes and his limitations. That's normal, because he works in an open environment, where all mistakes are noticed. If he doesn't talk about them, the others will.
At the other end of the spectrum, John Know-It-All will never accept he's mistaken, even if you prove it with all the resources you can. He will find out all sorts of ways to prove them wrong: "Those people don't do what we do", "This is theory", "I haven't seen this work" etc.

So there's one point to look for:

A person with a Good Ego is his/her first critic.

Intellectual honesty also includes the willingness to learn. Not only the technology you work with, but everything related to software development. Yes, that's hard, takes a lot of time and it's frustrating because you always find out you made mistakes. But software development is hard.

Continuous learning is the best way to transform a Bad Ego into a Good Ego.

My experience includes many moments of enlightment and of realization of my mistakes. I've come to understand that mistakes are part of life and that we should take maximum advantage from them. Understanding our mistakes and finding ways to correct them is how we evolve intellectually. During this process, a Bad Ego is transformed into a Good Ego.

The answer? Look for people who are intellectualy honest. This is an absolute requirement for what I call "good programmer".

---

Personal advertisement: I am PassionIT and help teams that develop high quality software. I train, I help improving and I work hands-on, depending on the needs. Contact me if you need help.
Alexandru Bolboaca-Diaconu

---

 

1. Software development is creative work

How do we know that's true: All rules that apply to creative work are known to give results for software development. For example: write the program, then re-write it at least once (see [1], [2]).

How do we know managers don't get it: The cubicle. The noise. Any other environmental factors that kill creativity.


2. Managing an IT project is different than managing projects in other domains

"In many ways, managing a large computer programming project is like managing any other large undertaking — in more ways than most programmers believe. But in many other ways it is different - in more ways than most professional managers expect."

(from [1])

How do we know that's true: Practices that work in other industries don't work in software development (for example adding more people to a project to make it end faster or motivating people with "the employee of the month" program)

How do we know managers don't get it: They still think people are interchangeable in a project team and they still use ineffective motivation and recruiting techniques.

3. People are more important than processes

How do we know that's true: No software company has succedeed only based on processes. Instead, all software companies that are very succesfull have very good people. The best example is Google.

How do we know managers don't get it: They still insist on the work processes instead of attracting talented people and instead of making sure that they reject the wrong people. (See [3] for an interesting story regarding this issue).

4. Good developers are cheaper than bad developers

How do we know that's true: Data from the industry shows that good developers can be up to 10 times more productive than bad developers (see [1]). From my own experience, there are cases when bad developers can be even worse than that. But good developers are never paid 10 times more than bad developers.

How do we know managers don't get it: They prefer to hire cheap but mediocre developers instead of hiring talented people.

5. No bad developer has ever become a good developer

How do we know that's true: Even Bill Gates said it. There are studies about it (see [5]).

How do we know managers don't get it: They still hope that bad but cheap developers will learn in time.

References:

[1] Frederick Brooks, "The mythical man month"
[2] Eric S. Raymond, "The art of Unix programming"
[3] Paul Graham, http://www.paulgraham.com/colleges.html
[4] Joel Spolsky about recruiting software engineers: http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html
[5] Saeed Dehnadi, Richard Bornat, Research Study about Programmer Aptitudes, http://www.cs.mdx.ac.uk/research/PhDArea/saeed/

---

Personal advertisement: I am PassionIT and help teams that develop high quality software. I train, I help improving and I work hands-on, depending on the needs. Contact me if you need help.
Alexandru Bolboaca-Diaconu

---