Software does not evolve; software degenerates
Today at lunch i felt taken by this concept once again. A long time ago it came to me that software, au contraire of living beings, does not evolve; the best description for it, in my not-so-humble opinion, is of a big tower of LEGOs building blocks: You start stacking them up and, when a certain amount of time passes, you end up with something that is no longer very stable at the base. It degenerates and – in time – you have to kill it.
Every good developer knows this simple fact: requirements change. They do, there is no point in denying it. And continuing to build on top of a base that was thought for one thing and now needs to do another one is just plain crazy, inevitably. The problem here is that, i believe, non-technical people still think that software is a living thing that keeps evolving and that, no matter what you come up with next, there will always be a way to make it do “just that one more thing that we need”.
So my question is: What is the best way to convince non-technical people that software needs to be killed or heavily re-factored from times to times in order for things to be maintainable and faster to build upon? I can’t help thinking about “Bruce Almighty”s quote when i ask myself the same question: “(BRUCE) So how do you make people love you without affecting free will? (GOD) Welcome to my world, son. If you come up with an answer to that one you let me know!”.
Related:
- Remote software developers I recently found myself wondering about what would be the...
Categorised as: complaints, computers, observations, software development
Programmers still do the same menial tasks that were performed 40 years ago, which is a huge waste of resources.
Industry seems to come up with new languages that do the same old tricks, whereas one would expect tools that increase productivity!
Fact is, no one has even yet provided an intelligent app to refactor these said LEGO blocks without starting over at the code level.
I wonder if it’s a way of justifying spending money in a company?
[...] Software does not evolve; software degenerates Instead I might say the world changes but software often doesn’t. [...]
I was reading a book yesterday, about how metaphors for things can help in understanding something, but it can also have drawbacks. By using a metaphor, you project the limitations of the thing you’re using as a metaphor onto the thing you’re using a metaphor for.
I thought of the metaphor I use for programming projects, which I saw as something that has the possibility of being perfect, but in contact with the real world, rarely ever is, one of the main reasons being changing requirements and too little time for fundamental (re)work.
Maybe the metaphor you’re using (the Lego tower) has limitations that the programming projects don’t. The thing is ofcourse, that when a program works, even a very brittle and ill-structured one, it will keep on working in exactly the same way forever, if untouched. Maybe changing your metaphor will bring you a new perspective.
It’s a fair point. If untouched it will continue to work exactly as before, assuming nothing else around it changes (i.e. external pieces that it connects to), though of course we are constantly building on top of it so it never truly will be untouched.
But you are right in the sense that it;s usually a good idea to look at problems with different metaphors; that way you increase the odds of other people understanding what you are trying to explain.
Metaphors are indeed usually used in explaining things.
Using a new metaphor for something you already understand, instead of an ‘old’ one, can give you new insights that can help you get past any illusory limitations the old metaphor might have projected on the thing.
Hey, you’ve discovered entropy!
I think that you’re not being quite fair, though. Decisions to re-write, or refactor, are taken quite often. In fact, I happen to know the project you’re working on right now is one of those occasions:-)
Of course, that doesn’t mean all re-work is bad, but is certainly proves that not all is good!
I think the trick is to know not just when to do re-work, but to know how far to go with it. And to know that when you’re doing re-work that it’s not just because of technical limitations or errors in implementation but most often because, as you also indicate, the requirements have simply changed!
That also means that when you do start over, the most important thing to do is to re-evaluate those requirements, and make sure you implement the new ones, not the old ones…
I know Wouter, but the amount of time that one spends discussing the obvious is what kills me slowly. I have seen those discussions over and over in different projects before and it still surprises me that people that should have a whole lot more experience than me don’t seem to have common sense at all
Ahem, not much I can say to that…
>(BRUCE) So how do you make people love you without affecting free will?
The same way your parents make you love them without affecting free will. Relationships are work, & it helps if you actually exist.
In response to your question, “What is the best way to convince non-technical people that software needs to be killed or heavily re-factored from times to times in order for things to be maintainable and faster to build upon?”, you already have the answer.
Make a small lego tower and have a few long rectangular blocks to represent new features.
Explain that putting the long bricks on top of the tower, sticking out the side, is like adding features to the system. They take the system in a direction it wasn’t designed to go.
Show that just like adding features to software, if you keep adding bricks to the tower on top of each other, eventually you’ll have to either start the tower from scratch or build little support towers under the bricks that are sticking out or it will be impossible to add any more bricks.
Few caveats:
1) Make sure your company culture is open enough for you to pull this off.
1) Show it to a manager you trust first. Get their feedback.
2) It is going to scare the crap out of management so you better have a plan ready to go on how to keep your company’s “tower” from falling.
3) Use responsibly, don’t get fired.
For more ideas, read the book “Switch” http://www.amazon.com/Switch-Change-Things-When-Hard/dp/0385528752
Good Luck
Thanks for the ideas. I will definitely check out the book
@edeion: I think the author is suggesting that “individual programs don’t evolve” similar to the way that individual people don’t evolve. Of course, populations evolve, but as programmers we don’t tend to work on that macroscopic level (dealing with thousands of programs).
It does evolve, and pretty fast on top of this : after only 50 years or so, computer programs are already at dinosaur’s era : big meat that no longer manages to adapt. So ok it looks like a dead end. After all, the news are not that bad, it’s time for a new era.
On a second thought I realize what your problem is likely to be and that your article is not as abstract as I imagined. You are in charge of a program that you want to improve drastically but your users thrown upon seeing it modified.
Wouldn’t it be possible to provide a compatibility layer that mimics the behavior of the current version on top of a new architecture. Those of your users open to novelty could take advantage of your work while backwards users could still do their work the old fashioned way…
My post was indeed about any computer program that one develops inside a big company (smaller companies are different, in the beginning, for obvious reasons). But the worst is that this is not a one shot thing. I have seen this happen in every single company i have ever worked and in time it gets really frustrating.
Regarding your solution, the problem is that it takes time. And if you get no time to refactor or start over with a better light shed upon the requirements, then you will probably get not time to create such a compatibility layer, unfortunately. Not to say that writing even more code will make it more unmaintainable in the long run.