When a Demo Is More Than a Demo

Turns out that my direct manager will be in the country next week, and we'll be having some conversations. One of those conversations will involve a demo of a site that I pitched to resolve some functionality that HR is looking for to keep track of some stuff. While I'm more than happy to present things to people who show an active interest in solving problems, I'm a bit worried about this demo because I've spent less than 5 hours on a mockup of how I envision things working. Generally the higher up the corporate latter one goes, the more functionality one needs to see in order to buy into an idea, and there's almost no functionality in the mockup aside from authentication.

So now comes the "fun" part: deciding how much of the demo will appear to be fully functional despite the lack of feedback from the various stakeholders who will undoubtedly want to have their voices heard.

Over the last 11 years, I've made a bit of a name for myself by presenting software that aims to solve "impossible" problems with interfaces that are as clean and efficient as I can possibly make them. As I am multilingual, the software is also multilingual from the initial conception all the way through until it's out the door and the first bug reports start coming in. Lag and stutter is unacceptable, so these things are generally minimised as much as possible, even if it means faking it until I can actually resolve the problem through some other means. Generally this works. However, the person I directly report to has a very keen eye for detail and can spot incompleteness from a mile away. Walking into a meeting with him to present an unfinished software tool would be a waste of his time and have the added consequence of making me look unprepared. So how much of this partially mocked up site should be brought to life in order to make it believable while also showing the potential with as little distraction as possible?

When there's a vague or unknown amount of work to be done, I generally take out my pad of A5-sized paper, a trusty pen, and start making a list. In this case, the objective is to write down all of the basic functionality that would be expected as part of an MVE, or "Minimum Viable Experience", which is typically considered the first version of the software for release. All in all, the list has 39 core functions, and an additional 17 that I considered as potentially useful, but unconfirmed.

With the known knowns down on paper the next step is to prioritise the features into three categories: must see, would like to see, don't need to see. Functions such as a personal profile page and customisable avatar are clear examples of "don't need to see", while other elements, such as the ability for a manager to see a list of all the information in a simple, sortable table, would be "must see". Going through this process I found 21 things that must be completed, 9 things that would be nice, and ten that could be postponed until the project was officially accepted. From the pile of "potentially useful" features, I picked out the three best and appended them to the bottom of the "would like to see" pile.

Now that the basic accounting is out of the way, it's possible to determine how much time will be needed to get the thing ready to show off and what needs to be done to make it happen. The demo will take place on Tuesday afternoon, and there will not be any time to work on the code after Monday night. That leaves just three business days to get it done in addition to all the regular things I do for the day job.

Impossible? Hardly. The timing will be quite tight, though. That said, this is what I do. In the face of my own stupidity, I double-down and get things done in order to present something to people. As this is supposed to be a demo, half the functionality will likely need to be modified for new requirements, or the UI — which is using non-standard colours — will need some tweaking to bring it back in line with corporate expectations1.

For quite a lot of this year, I've not really felt very useful at the day job as a result of the endless meetings, endless reports, endless documents, and rage-inducing corporate politics. When I get to hammer out a little bit of code in order to make the impossible into the ordinary, though? This is when I can finally feel accomplishment.

  1. This would be a shame, though, as I opted to go with a nice orange colour scheme just to shake things up visually. There's only so much navy blue one can look at in a day …