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.