Intriguing title isn't it?
Especially if your unfamiliar with the abbreviation, I'll get back to it.
I've mentioned briefly in previous blog post ("Testing is more than running the software") about how I've been working on a performance testing project ("AAPT") for building the Android Source code using Electric Accelerator, a project which I plan to describe in better details in another blog post.
One of my key drivers for that project was to make the results visible to the rest of the organisation, because nothing fosters engagement and curiosity in your organization about the work of testers like showing people the results and making them visible.
On the other hand I really wanted to start small and just get something out there, that way I knew if I got people curious, dialogue and requests for improvements would follow.
So I choose to publish the results on an internal wiki page that I created.
Easy enough since the wiki server we use has XML-RPC & REST support.
The results where published in a very basic HTML-table, the information was there, and that was basically it, your everyday tea and biscuits.
So on Friday evening while making dinner I got an IM message from our chief architect Eric Melski.
Aha he want's marmalade as well!
I responded after thinking a bit:
See I have always taken pride in the sense that I want to write good solid code and produce solutions that I can build on in the future, but at the same time don't over-design it, and trying to strike that balance in between getting it done now and taking a bit of extra time to invest for "future me" (When in doubt: "MORT").
At this point Eric answered:
And I said back:
To which Eric responds:
Now for those of you who don't know it YAGNI stands for "You Ain't Going To Need It", and it refers to the habit of engineers to over-design stuff and put in extra features when not needed.
As I was trying to come up with a good response, all my arguments faded away as I realized Eric was spot on.
I realized that I could have Eric's proposed solution implemented in a few hours, and so I asked him how GNUPlot prefers the data structured.
I knew I was hooked now and that I wouldn't be able to go to sleep until I at least had done some tinkering.
Eric also added that he was good with GNUPlot, and offered to send over the GNUPlot part, script and makefile. And then we bounced some ideas around.
I ended up spending 3 hours on Friday evening implementing a separate class that takes care of analyzing all our performance data, dumping it into a text file, then utilizing Eric's GNUPlot solution, and in the end updating the wiki page with the updated plotted graph.
It was fun :-D
At times like this it's invaluable to have a senior colleague to chat with that you can bounce some ideas with, and who can remind you to keep the balance in between "Overkill vs. Too hacky".
Eric is that guy, and being chief architect, and one of the top 3 developers that I've met in my career (how ever you measure that) means he's not one who's opinion I easily discard.
So always try to keep a balance for your projects, and ask yourself the hard question. Am I going to need this?
Or even better, seek out the advice from a senior colleague that you respect and ask them for their view on the matter.
I have been reminded of YAGNI, and I will be adding GNUPlot to my tool belt going forward.