In 2002 I was asked to add graphs to a financial website.
I started by considering off-the-shelf freeware Java packages, but a few hours of research suggested that none of them were quite customisable enough
(as may well still be the case in 2008, perhaps astoundingly). So I decided to write my own graph package – the third or fourth I’ve done, I think.
There was an immediate problem, because my boss thought it was all taking too long (this after a week or two) with not enough visible progress. The perception,
after I’d shown him a wiggly line generated on the first day by a freeware package (subsequently deemed inadequate) was “we’re going backwards”. It was clear that there was a potentially career-limiting loss of confidence here. Also, I was working off-site, and the company didn’t really have any way of monitoring me – adding to concerns that what I was doing might not be sensible.
The boss took to ringing me up more and more often to demand progress reports. Naturally, he would always do this just as I was in the middle of debugging the axis generator, or some other heads-down task, and so he’d get an unsatisfactory or distracted response… I was becoming a classic instance of a techie “going dark”, and crisis was imminent.
After one particularly painful meeting, I solved the problem by suggesting I send twice-daily email updates. This turned out to be a wonderful and rare example of coming up with a simple, effective management tool.
Typically, the emails would take 20 minutes to write and be 10 lines long, saying something like “I’ve done X, tried Y but it didn’t work because Z, am doing W next”. They didn’t generally require much feedback. The great thing was the discipline of having to report what I’d done every half-day. For all I know, the boss hardly ever read the reports, but this didn’t matter – by telling him what I was doing, I’d implicitly given him the opportunity to monitor it, in a non-intrusive way.
I’d describe what I was doing in the language of features, e.g. “shall I add a logarithmic scale option?”or “now I need to add a module to calculate and display dates
properly in different time ranges” and the response was generally something like “yes, great idea”. Confidence was restored.
I’m still proud of that graph package, a worthy successor to the DOS/Windows/OS2 ones I’d done previously. It took two months, and the main thing I
remember was that there were twelve off-the-peg graph sizes: Micro, Tiny, Miniature, Small, Pocket, Medium, Compact, Big, Large, Huge, Colossal and Gigantic.
(Pocket started off as “Undersized”, but I decided that name wouldn’t do.) Micro was so small that it only made sense as a footnote to other web pages. As for Gigantic, it lived up to its name, and was a response to certain awkward users of the website who kept complaining that the graphs weren’t big enough. Later on, I refactored it so that you could have dynamically updating real-time graphs with all the same sizes and features, viewable in an applet.
As for the “management technique”, I suppose it was a bit like Scrum. For me the moral was that you have to keep management updated, proactively if possible.
Also that it’s often reassuring to give people detail, even if they don’t want to drill down into it.