{"id":33,"date":"2007-02-22T04:21:19","date_gmt":"2007-02-22T09:21:19","guid":{"rendered":"https:\/\/billhiggins.us\/weblog\/2007\/02\/22\/disciplined-laziness\/"},"modified":"2007-02-22T04:21:19","modified_gmt":"2007-02-22T09:21:19","slug":"disciplined-laziness","status":"publish","type":"post","link":"https:\/\/billhiggins.us\/blog\/2007\/02\/22\/disciplined-laziness\/","title":{"rendered":"disciplined laziness"},"content":{"rendered":"

The other day, I thought of a clever solution to speed up an important Jazz<\/a> 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.<\/p>\n

But I haven’t done this.<\/p>\n

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.\u00c2\u00a0 So although the 20-40% improvement is certainly relatively<\/em> significant, it isn’t of any practical significance to users.\u00c2\u00a0 After all, who cares if something that currently runs in a ‘speedy’ 2 seconds were reduced to 1.5 seconds?<\/p>\n

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<\/a>, which the team as a whole rigorously observes.\u00c2\u00a0 The benefits (0.2 – 1.6 second reduced response time) simply don’t justify these costs:<\/p>\n