Entropy in software development
Tuesday, 5. February 2008, 09:22:59
Quite often I hear developers or managers acting very surprised about the fact that an application "doesn't work".
I am never surprised when an application doesn't work. Probably because of my engineering background, and probably because I can still remember the second law of thermodynamics:
The entropy (=randomness, disorder) of an isolated system which is not in equilibrium will tend to increase over time, approaching a maximum value at equilibrium.
This law states something that we all know intuitively: it takes effort to move things in the desired direction. It doesn't matter whether we're talking about a carpenter trying to build furniture, a cleaning person trying to keep a room clean or a software developer trying to develop an application.
This means that the normal state of things is for an application not to work according to specifications. That's part of the reason why programming is hard: you have to fight entropy.
The reason why people are surprised with an application that doesn't work is that they don't realize just how hard it is to fight entropy in a software project, avoiding in the same time the other big enemy: complexity. Many people don't understand that programming actually means working with ideas.
What comes as a natural consequence of the above law is that I am always nervous when an application we develop seems to work fine. That's just not natural.
When I say "seems to work fine", I mean that there is no reasonable proof of the fact that the application is working fine. Of course, we can't prove that an application just works (no matter what marketing tries to tell us). But there are many examples of projects that were driven back because they lacked this proof and because they discovered at some point that inside the seemingly good working box there were many lurking bugs.
The first rule that results from this reasoning is:
Never trust your developers when they say the application is working fine.
Only trust them when they prove it to you with: unit testing, functional testing, beta testing (with real users) etc. Developers' mindset is about making the program work, not making it fail. That's why not many of them are good at testing their own modules.
In the end, remember that it's normal for an application not to work. It's unnatural when the people working on it say that it works without investing too much effort into it. The entropy is hard to beat.
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
I am never surprised when an application doesn't work. Probably because of my engineering background, and probably because I can still remember the second law of thermodynamics:
The entropy (=randomness, disorder) of an isolated system which is not in equilibrium will tend to increase over time, approaching a maximum value at equilibrium.
This law states something that we all know intuitively: it takes effort to move things in the desired direction. It doesn't matter whether we're talking about a carpenter trying to build furniture, a cleaning person trying to keep a room clean or a software developer trying to develop an application.
This means that the normal state of things is for an application not to work according to specifications. That's part of the reason why programming is hard: you have to fight entropy.
The reason why people are surprised with an application that doesn't work is that they don't realize just how hard it is to fight entropy in a software project, avoiding in the same time the other big enemy: complexity. Many people don't understand that programming actually means working with ideas.
What comes as a natural consequence of the above law is that I am always nervous when an application we develop seems to work fine. That's just not natural.
When I say "seems to work fine", I mean that there is no reasonable proof of the fact that the application is working fine. Of course, we can't prove that an application just works (no matter what marketing tries to tell us). But there are many examples of projects that were driven back because they lacked this proof and because they discovered at some point that inside the seemingly good working box there were many lurking bugs.
The first rule that results from this reasoning is:
Never trust your developers when they say the application is working fine.
Only trust them when they prove it to you with: unit testing, functional testing, beta testing (with real users) etc. Developers' mindset is about making the program work, not making it fail. That's why not many of them are good at testing their own modules.
In the end, remember that it's normal for an application not to work. It's unnatural when the people working on it say that it works without investing too much effort into it. The entropy is hard to beat.
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
Hmmm… an effective technology comes with a befitting name. ‘Agile’ as they say it. The long and abrupt, turns and twists in the alley of Software Development process now face the inevitable. Welcome to Agile Software Development methodology. With this, the Software Development process would now hopefully be more structured, less convulsive (for its developers of course!) and markedly disciplined.
By anonymous user, # 26. February 2008, 05:53:18