There is no spoon

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

---

 

Profesionally, I have an engineering background. Because of this, I learned two basic things during the college years:

1. In a computation, the expressions that are an order of magnitude less than the others can be neglected
2. You have to compute the magnitude of the error for computations


The first principle helps you do the practical stuff quicker, by ignoring what you know it's not important. The second principle helps you keep disasters from happening.

My background often turns me into the most pessimistic member of a software development team. I don't think that's my fault but that my colleagues are too optimistic. I've wrote before about wishful thinking in IT, and the two are related.

The first principle is called in software "levels of abstraction". This basically means designing an application from different points of view and deliberately ignoring the details that are not related to the current level of abstraction. For example, when designing the network structure for the application, don't think about the types used for the database primary keys. Of course, this is an exagerated example, and usually the boundary is thinner, but that's the point.


The second one applies in software through risk management and error minimization for estimations. Whenever I look at a task, I am always thinking:
a) how could this be implemented?
b) how could this be tested?
c) how could this go wrong?
d) what can be done if it goes wrong?

Those last two questions always make me think twice before comitting for a deadline, even if the estimate seems large enough for everybody else.

There are however methods to avoid those problems, once you understand that the IT industry is a little bit different and that other people had the same problem and found solutions. A methodology for estimating (even a very simple one) helps a lot with error reduction, while continuous risk management allows avoiding the worst case scenarios.

In the end, success is possible in software. Only one thing is needed: Discipline. And that's all in your head...