A question I face in software projects on almost a weekly basis: do we implement the feature Right or do we do it Right Now? Of course ideally we want to do it Right and now, but sometimes that's just not possible.
Case in point: we have a bug in a website that we deployed about a month ago. The bug is fairly serious, it's impacting the user experience and the stakeholders are quite rightly clamouring for a fix. On the other hand their critical date has passed - the bug has already done more damage in the last two weeks than it's likely to do in the next two.
We can fix it right now using a perfectly good proprietary solution or we can wait two weeks for a feature to be rolled out across the corporate web stack, enabling a more standard and simpler solution. There's no doubt that in an ideal world this is the better fix.
There are three ways we can go:
- Do It Right
- Do It Right Now
- Do one now and the other later
I think the choice you make should come down to business value and risk:
- What is the additional value of doing it Right?
- What is the business cost of delaying to do it Right?
- Does either solution involve appreciably more risk than the other?
- What is the additional cost of doing the work twice?
Additional value of Doing It Right
There must be something that makes the Right solution Right. Is it more robust? Easier to support? A strategic enabler? In our case it moves a lot of the work and maintenance responsibility to another team and delivers a business-standard solution. That's a lot of Win.
If it doesn't deliver any value perhaps it's just an engineer's whim - hey I've been that engineer ;)
Do It Now!
Business cost of delay
Presumably there's some pressure to Do It Now and not later. In our case the bug is making some user interactions fail, alienating the users and probably doing reputational damage. Delaying another two weeks would be significant Fail.
No pressure and no cost? Then you're probably not even having this conversation - hold off and Do It Right!
In my example above there's a significant dependency risk in the Right solution. If I make that decision, I'm relying on another team to deliver in a timeframe that I have to commit to my stakeholders. On the other hand, there's also a small risk that the Now solution won't actually work...
Cost of Doing It Twice
There's a cost to doing anything, and double the cost in doing it twice. I don't care if your project doesn't have an explicit budget - while your team's doing the Tactical then the Strategic implementation they're not burning down your product backlog.
If the cost of the delay plus the value of doing it Right is greater than the cost of Doing It Twice, then maybe you want to go for both the Tactical ans Strategic solutions..
If not, then does the value of Right exceed the exceed the cost of delay? That should tell you which way to go.
And what have we decided? In the end the engineering team didn't deliver the proprietary solution before the new feature hit the corporate stack anyway.
I wrote almost all of this post a couple of months ago, when I planned to build my own website (previous post). That would have been Doing It Right, but the cost of delay just became too high. Posting on Blogspot is Doing It Right Now and I'm really pleased with that decision.
Will I Do It Twice?
Having my own site still has its attractions, and if it's worth it maybe I will. This blog may provide part of that answer...and I think that will form the basis of my next post
Damn - it's almost as if I planned this thing!