There is no spoon

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

---

 

In a previous post I criticized some of Jeff Atwood's ideas. Today it's time to step in and defend him.

Jeff Atwood's today post talks about being able to run a program in 600 lines of code. He calls for an exercise in minimalism:

What can you build in 600 lines of code? Think of it as an exercise in minimalism. Does your preferred language or environment allow you the freedom to create something interesting and useful with that constraint in place?

The comments to this post are mostly jokes for a matter that is quite really serious.

I suppose that everyone's heard by now that the software industry has a horrible failure rate. 30% of projects never finish, while other 30% of projects finish but not in the due time and/or budget. That leaves only about 1/3 of the projects that are really succesfull.

Imagine now that one in three cars would explode and another one would be delivered one year late. Or that one in three houses (bridges, airplanes and so on) would fall apart. This is the sorry state of the software development industry at this point. Our only luck is that our mistakes kill much less people than other industries.

There are many reasons for the failure rate. Some of them are related to the fact that most managers don't understand how software is produced and don't know how to improve the process (hint for the managers: read for starters "The mythical man month", "Code complete", "Peopleware" and "Software Estimation: Demystifying the Black Art"). Some of them are related to the education of programmers.

When all those things are done well, the final product has a few characteristics that show it's good. The Tao of Programming explains it in a very expressive way:

A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity.

A program should follow the `Law of Least Astonishment'. What is this law? It is simply that the program should always respond to the user in the way that astonishes him least.

A program, no matter how complex, should act as a single unit. The program should be directed by the logic within rather than by outward appearances.

If the program fails in these requirements, it will be in a state of disorder and confusion. The only way to correct this is to rewrite the program.

The connection between good software and fewer lines of code is well documented (again, see "Code complete"):

The more lines of code your software has, the greater the number of bugs.
The more lines of code your software has, the longer it takes to solve one bug.
So writing less code helps you write good software.

Any software can be written badly. The experience shows that this category of software usually fails. So, how's it gonna be?

---

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

---