The worst decision you could ever make, and will anyway do it...
I'm sure this has happened to you. Probably many times over your long career in software development. You wake up, take a long hard look at yourself in the mirror and courageously make that decision you had been wanting to take for the past few months. You go back to the office, take your manager aside and in a decisive tone deliver the news, the bad, bad, bad news: we need to rearchitect the system. All of it? No, that's the best part! Only this (very critical, absolutely critical) small part. You don't mention the "critical" part of course. You know better.
Your manager looks at you, silently thinks it over for about 0.35 seconds and then solemnly states: that sounds like a plan, make up the Gantt chart and deliver it to me, I'll take it to the boss.
And so it is done. You have taken the first step to re-write (from scratch, obviously) that part of the system. Did you make the right decision? You say only time will tell?
I beg to disagree, and so does Uncle Bob. You just made the most stupid, crazy-ass, fully incompetent, narrow minded, ignorant, and hole-digging decision of your life and soon you will regret it. Hopefully for the rest of your life, so that you don't do it again!
Re-architecting (read re-developing from scratch) a part of your system is the single most waterfall-ish idea that could cross your head -- and it will make you fail...
I've been a developer that made that decision, and still regret it today.
I managed a project where I was the one accepting to re-implement that part of the system, and still regret it today.
And if that was not enough a colleague at work did the same decision and he is already in his 3rd re-implementation of a module that should take 2 weeks to implement (his words) and he has been at it for more than a year... (his boss is still saying "ok" after thinking about it for 0.35 seconds...)
at
21:47
Your manager looks at you, silently thinks it over for about 0.35 seconds and then solemnly states: that sounds like a plan, make up the Gantt chart and deliver it to me, I'll take it to the boss.
And so it is done. You have taken the first step to re-write (from scratch, obviously) that part of the system. Did you make the right decision? You say only time will tell?
I beg to disagree, and so does Uncle Bob. You just made the most stupid, crazy-ass, fully incompetent, narrow minded, ignorant, and hole-digging decision of your life and soon you will regret it. Hopefully for the rest of your life, so that you don't do it again!
Re-architecting (read re-developing from scratch) a part of your system is the single most waterfall-ish idea that could cross your head -- and it will make you fail...
I've been a developer that made that decision, and still regret it today.
I managed a project where I was the one accepting to re-implement that part of the system, and still regret it today.
And if that was not enough a colleague at work did the same decision and he is already in his 3rd re-implementation of a module that should take 2 weeks to implement (his words) and he has been at it for more than a year... (his boss is still saying "ok" after thinking about it for 0.35 seconds...)
Labels: agile, implementation, lessons learned, project management, waterfall
RSS link
3 Comments:
So, what's the answer then? There are those pieces of legacy code that have worked well but so much other stuff has been piled on them that they are starting to creak under the weight they were never supposed to carry. It must be possible to fix them!
Let me guess: Continuous, small improvemens?
But what if the changes required are so big they are impossible to do in the small? Or does one just have to find a way to do it incrementally? Even if it takes more effort than rewriting from scratch?
I'm not sure. But I agree that working code is such a precious resource that it should never be squandered. Look what happened to Netscape.
By
sti, at January 11, 2009 2:07 PM
What are the ways to avoid whole "mess"? If developer or team does not understand/notice they are sinking into the "mess" what are the remedies for that? I have some experiences that managers do not ask afterwards when release is out how did you implemented it? This was release 1.0, is it possible to make release 2.0 based on that code asset? What are your "tools" for that?
By
Anonymous, at January 13, 2009 9:00 AM
Great comments guys. But you forget what gets you into the mess in the first place: wanting to go faster without caring for the quality of the code.
So, the solution is simple, but not easy.
Scaffold the code you have with proper unit tests. If the code is fragile you want to make sure you know when it breaks ASAP!
After scaffolding you have to refactor it. One piece at a time.
Someone once compared it to letting a plant grow around a tree. At the first the plant is small, then it grows until it surrounds the trunk of the tree completely. After this, the tree dies (lack of light and oxygen), but the plant survives, and how has something to hold it steady vertically.
If you try to re-do something (large) from scratch what makes you think that it will be better when you are done?
And how about knowing when you are done? The example i mention in the blog is real. There's this guy that has to implement a piece of middleware and has done it 3 times. This is something that he says will take 2 weeks every time he starts it and it has taken many months already if you put those three attempts together!
What he should be doing is refactoring the bad code when he sees a problem, and improve the code at all times, not rewriting the same thing over and over again...
By
Unknown, at January 13, 2009 10:32 PM
Post a Comment
<< Home