On Weekly Demos
Fear and hope live in the heart of any developer about to conduct a live software demo on Friday. Will it be crushing, as the inevitable bug surfaces? Or will you be triumphant over your own machinations of logic and demonstrate your coding prowess to your peers while justifying your paycheck?
Getting everyone on the same page and providing visibility is awesome. Even in small teams, it can be hard to see the concrete contributions of other team members. If teams are highly functional and do all the things they’re supposed to do to perpetuate awareness, demos can provide a platform to shine and align while building cohesion.
Each team member has a different vision of what a product should be, before it’s constructed. Even with extensive empathy maps, wireframes, prototypes and designs, it’s impossible to know exactly what a product will be until it’s made. This is why showing off progress is great for momentum, for cohesion and for just a little fun. Everyone feels good when it works out, and it’s low risk enough to not impact things greatly when it fails.
However, weekly demos come at a price. Objectives are defined on Monday, reached on Tuesday or Wednesday, refined on Thursday and prepared for display on Friday. Proof of concept achieved, the idea is considered ‘done’ by everyone involved, from leadership to sales. However, as any code pusher should recognize, functional is a far cry from done.
A successful product is not built upon endless cycles of demos. Demo code is rife with bugs and technical debt. As functionality is the primary objective, important considerations like documentation, maintenance, organization, style, optimization and proper considerations to difficult problems, like what to name things, are ignored in favor of the next ‘demoable’ feature.
This practice then leads to the nightmare scenario where everyone in the company feels very good about the visible progress of the product. Decisions are made, deals are struck, hockey sticks are drawn and hires are made, all based off the illusion that interactive demonstrations equate to concrete progress being made towards an end goal.
Behind the scenes, under the hood, a monster lurks, and it will destabilize the product and the company. It is easy to show an idea in isolated circumstances or show ‘progress’ by haphazardly hacking the product. Demo features are neglected to be integrated properly in a visible, organized approach. Technical debt, a quasi-quantifiable measure of how much work is needed to move a codebase from ‘what it is’ to ‘what it should be’, is rarely evaluated.
Until, that is, a product enters the final half of it’s development cycle and passes the 90% mark. Instead of moving quickly towards the end goal, here is where naming and organization begins to be important as discrete pieces need to interoperate. Scattered and tangled strings of logic need to be unknotted before one can make measurable progress. Demos no longer become a weekly ambition, instead, the goal is to not break everything. Progress grinds to a halt, for the slightest change causes all the gears to misalign. Throwing it all out and starting again begins to be discussed.
Excitement and passion around a product is paramount, especially to the people who spend their lives building it. There is a place for team-wide demos and this is when a value adding feature is complete and ready for customers to use. Otherwise, a team risks entering into a false sense of product, which puts everything at risk.
