Hey you, developer! Learn a bit of business speak!
In a comment to one of my posts, Dave Mertens said:
I often wish I had the luxury the throw away the current code and start from scratch. Why. Because my manager ask me how long it takes to fix just this bug. 80% of the bugs (luckily we don't have that many bugs) are fixed within 2 hours including writing tests. Than he asks me how long it takes to rewrite the damn code.
It is interesting to note that the questions you ask select the answers you want.
When you give someone a choice between 2 hours of fixing code vs. 3 days of fixing code, the decision is always going to be in favor of 2 hours.
At one point in my life I was asked if I stopped beating up people. This is a twist on the old “have you stopped beating your wife yet? yes/no” question. I answered in Mu. Then I spent another ten minutes explaining what I meant.
When someone asks me those types of questions, I correct the question, before I answer. Because while you may ask questions to lead the answer in a certain way, there is nothing that says that I must go that way.
The right question is: How often are we hitting on bugs for this same code path? Then asking about how long it takes to fix the whole damn thing.
Oh, and make sure that you can fix it. There is nothing a business likes less than spending time & money on solving a problem and ending up not solving it. Leaving aside what it does to your credibility and the trust relationship with the business.
Comments
But do you really think rewriting something from scratch just to fix some bugs or messy design is a good idea? Throw away everything and start with nothing but a faint idea an eagerness to work? No wonder manager's dont believe that, it's a nonsense... I'd rather collect ideas for new functionalities that are impossible with current architecture, or design a completely new GUI with another technology, and then decide to start from scratch because the gathered changes are so massive that it's easier to rebuild everything than modify existing code.
Of course you're not gonna rewrite the full solution. The original post was about fragile code that often tend to produce bugs when it's altered because it's already changed so many times.
Wanna talk about business speak? I just say it in statistics and graphs. Using the issue database I keep a sore of how many issues a certain feature or component get during it's lifetime, the time between bugs and how long it takes to resolve those issues.
So when my graph shows management that the time between issues for a feature or component decreases and the time to solve it increases they ask me how I can reverse that trend. And that's the point I can convince management it's time to rewrite that feature or component.
And remember: That all your tests pass doesn't mean your have high quality code, it only tells you that it works.
@Dave, I oversimplified a lot, just because I have heard too many programmers whining that their project is a crap and should be blown up and started from scratch. Your approach is rational and you are well prepared for convincing your co-workers that some unusual actions need to be taken - this is a completely different case.
Using the issue database or specifying lots of new features are nice ways of convincing the business that a rewrite is the correct path. Yet i have personally experienced a situation where "the business" felt so heavely invested in a project that they just kept throwing time and money at bug fixes and hack extensions and simply did not (want to) realize that the product had to be restructured from the ground up to ever realy become a success.
Ofcours in this case the "bad code quality" extended across the architectural design, all the way up to features beeing poorly thought out.
Also i like to whine about rewrites :)
I reckon I only ship 1/3 of the code I write. The other 2/3rds consist of early iterations of the feature, bits of 10 minute prototypes, experimentation with language features in Notepad etc.
My code is smaller and simpler (thus less buggy) by doing this.
Rafal,
Pay attention to the context in which this was written, we aren't talking about rewriting the whole app. We are writing about rewriting a fragile component inside an application
Right. Sorry.
One concept many people on the "business" end of our profession don't understand is sunk costs. Whatever resources have been used up to this point is gone and are never coming back, so they should look forward and say "what will all these bug fixes from this time forward cost me v. what benefits do I get by re-writing". If more people on the business side did that, life would be much easier.
Then again, on the development side we often tend to underestimate the time it'd take to rebuild an applicaiton. The "Oh, that shouldn't take more than a few months" one off said to a manager without really thinking it through gets us in a lot of trouble.
Comment preview