The other day, I thought of a clever solution to speed up an important Jazz function by perhaps 20-40% (depending on a set of environmental factors). I eagerly documented the solution in a bug report and CC’d several teammates. Several times over the past week, I almost went ahead and just coded the solution, because I was so happy with its cleverness.
But I haven’t done this.
Fortunately for users but unfortunately for my idea, the function in question already runs as fast (1-4 seconds) as users expect it to run, given the nature of the function. So although the 20-40% improvement is certainly relatively significant, it isn’t of any practical significance to users. After all, who cares if something that currently runs in a ‘speedy’ 2 seconds were reduced to 1.5 seconds?
So it’s been with great discipline (and a bit of angst) that I’ve abstained from writing this clever code, basically because of the YAGNI principle, which the team as a whole rigorously observes. The benefits (0.2 – 1.6 second reduced response time) simply don’t justify these costs:
- time to implement
- time to test
- potential defects (the current implementation has been stable for six months)
- increased complexity (it’s clever, you know)
- opportunity cost of not doing other work which is of practical use to users (backlogged enhancement requests, UI/UX improvements, bug fixes)
The reason I bring this up is because it demonstrates the powerful temptation to implement a clever or elegant solution despite the fact that it lacks a compelling problem. I consider YAGNI to be a fundamental principle of my personal development philosophy, yet I still found myself tempted to implement the solution once I had fallen in love with its cleverness and efficiency.
So … I’ll be patient for now and my solution will remain unimplemented, but documented in a bug report. If, over time, other system factors cause the response time to degrade, perhaps the solution’s value may increase enough to justify its costs.
Or not.
Hi Bill,
You raise some good points on why your idea shouldn’t be implemented “right now.” The current environment certainly doesn’t call for it, and I think you would be adding in a higher maintenance cost which is NOT “a good thing.”
I hope the Jazz team has an “ideas on pause” repository for situations like this. I think you need a better holding space for the idea than just a bug report, imho. Bug reports tend to get lost in the noise and don’t highlight the fact this was really an enhancement instead of a bug fix.
Your idea is still good and valid. And there may be a time when the performance increase really is needed. That’s when it would be a good time to dust off the high level design you put together and revisit the idea. Our products change with time, so yesterday’s bad idea might be tomorrow’s good idea. Matter of fact, I think it’s worthwhile to document why the enhancement wasn’t done at this point in time. In two years, you’re not going to remember the details of the conversation, so it’s worth adding a note to the high level design indicating why it was mothballed.
Thanks for the note Glen.
I can assure you that it’s fairly easy to keep track of architectural musings like this.
For one thing, the Jazz project is composed of a set of small, highly modular teams, so it’s relatively straightforward to keep track of in-flight ideas. For instance, there are exactly four people (myself included) who directly care about the idea I mentioned above.
Also, we do our work in 4-8 week milestones and each component lead reviews each of his/her open tracking items (bugs, enhancements, etc.) at the beginning of each new milestone.