There is no spoon

I have been trying in those last days to write a document describing some best practices that should be followed by one of my projects - and, why not, by any other project. Trouble is, I find this a very difficult task, not because I wouldn't have enough material or inspiration, but because it's difficult to make it convincing.

It all starts from a simple fact: I know bad code when I see it. I know bad design when I see it. And, whenever I make those judgments I am aware that (A) I think of human nature and its limitations, (B) Many other people from the industry would agree with me and (C) My colleagues may not agree with me.

Regarding the first point, it is important to understand that people write software for people. And people are limited, they make mistakes, they have difficulties finding the simplest solution, they tend to overdo or to underdo, they don't know how to express something that will be easy to understand by others. The source code is nothing but a communication medium, only it's a three-fold communication medium: the developer who wrote it talks to the developer who reads it, and to the user who needs it, all through the code; the difficulty is that the user sees another representation of the code, which communicates differently.

If this communication is broken, problems start to appear. If you cannot read your code as a story, you are bound to have troubles at some point. If your application doesn't tell its story to the user, he/she won't be content.

Regarding the second point, there are countless books talking about best practices. "Code Complete", "The Mythical Man Month", "The Art of Unix Programming", "The Cathedral and The Bazaar", "Refactoring" and even "The Tao of Programming" are well-known books that are all cited, used as reference, implemented (Source Monitor's Complexity metrics is implemented based on "Code Complete") and required reading. But I still need to talk about them.

And this takes me to the last point. Many developers I know chose to be programmers because they felt they can do anything. To some extent, it is true: a programming job gives us power to mold ideas into something we like.
On the other hand, this view is terribly wrong. You cannot do anything, because you are limited as a human being.

This is a truth that's difficult to grasp, but it's the path towards mastering software development.

---

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

---

... is that we are working with ideas, not with material items.

The relation between people and ideas is fundamentally different from the relation between people and material items. For one thing, material items are perceived in the same way by different people (unless some of the participants are under the influence of some perception-altering substances). Material items can be described completely by diagrams and numbers.

The IT industry has gone to a great length of defining ways that would allow completely describing ideas. We have UML diagrams, templates for writing technical documentation and so on. We have ways to describe data and the transformation it suffers. We also have ways to describe the user interface.

The problem with the description methods we're using to describe ideas in IT is that:

• It's really difficult and time consuming to completely describe an idea (try to read Kant or Hegel to realize how difficult it is)
  
• Different people understand the description differently
  
• It's difficult for people to understand the description completely, to take into account all the details
  

Besides this, ideas evolve, and the people who need the application expect them to be easily included in the implementation. It's very difficult to dissociate an idea from its programmatic representation. Ideas are easy to modify; the implementation is itself immaterial; so why is the implementation so much difficult to change than the idea itself?

In order to prevent misunderstandings from happening, we are testing the "materialization" of the ideas; in other words, the implementation. But how do you test an idea? It's not a matter of fitting a mechanical piece in a mechanism. It's about comparing the mental image of the idea with the actual implementation. But you can't actually touch it, move it, look at it from all angles; at least not physically.

And then, there's the relation between users and their applications. The computer is different from any other tool known to man because of a few key characteristics:

• It processes information and the result is information
  
• It gives good results only when given good input
  
• It gives wrong results in any other situation
  
• The user cannot touch an application
  

Therefore, the user has to form a mental model of the application and of how it works. So we are back to the same problem of perception of ideas. The user's mental model about the application is not bound to be the same as the one of the developer, of the producer and so on.

This essential difficulty is responsible for the most problems we face in software development. And, because it's an essential difficulty, there are no ways to avoid it, only to alleviate its effects.


The first solution that comes into mind is to minimize the communication chain. If the mental model gets more corrupted the more it travels then make it travel less.

Open source is a succesful model because the people writing the software are the same people who need it, and they can take decisions regarding it. In other words, they are bound to have a similar mental model because they need the same thing, and they are free to adapt the ideas.

Agile methodologies are succesful because the communication chain is the shortest possible. The customer is part of the team and he is the one explaining the mental model directly to the people responsible with materializing it.

All the other methodologies have proven in time to be impractical. Completely documenting an application in UML is less productive than writing the application and adapting it as it goes. In fact, completely defining an application means that we are creating a complete representation of the application in another language, and isn't that exactly what programming does? Except that you can run a program and you can, with some extent, use your senses with a program. That's impossible with another abstract representation of the same idea.

The other way to alleviate the difficulty is to use the right people for the job. Since defining a mental model for the application is a human problem, it's dependent on the individual. People with the right mindsets and with a certain mental agility that allows them to adapt to exotic mental models manage to form a mental image that's much closer to the one that's transmitted to them. And, with experience, they come to the point where the fill in the missing parts with the correct pieces of the puzzle (for a very interesting discussion on the expert mind, see this article).

To summarize, if you want your software project to be succesful, do the following:

• Minimize the communication chain between the vision and the implementer
  
• Use the right people in your team
  

I believe this to be the basis for any succesful software project.

---

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

---

 

On Monday and Tuesday I've participated to a very useful training, "Train the Trainer", with TMI. I knew that those guys were the best, because while I was still employed I participated to another amazing training from them, "Practical Leadership".

Most of the training was about us, the participants, trying to present, being filmed and then comment on how bad presenters we were. Even though I've held trainings before, I've gathered feedback from participants and all that jazz, I found out during this training that I make two big mistakes: I talk very slow and I don't look at the audience. On the good side, I convince the audience that I know what I'm talking about. Putting it differently, I'm very good at "What" but I have to work on "How".

What I don't understand though is why nobody ever told me that? It's ok, let me know, so I can improve myself. I realize that I still don't do many things right regarding social skills, but that's mainly because I spend 12 hours a day looking at a computer screen or reading books. That's my craft.

To conclude, the training was really good; I am decided to improve my presentation skills, and I know exactly what to look at. Life is interesting as long as you learn...