Tag: developer tips

The Power of a Great Demo

I went to school at Western Washington University and got a degree in English, with a concentration in Creative Writing. In damn near every writing class, you’d hear the same 3 words. Show, don’t tell.

Independent of writing style, a scene inspires and communicates more. A quick example:

Version 1:
Bob was hurt and furious after Marie’s “I miss you.” text. “2 months and this shit?” he thought.
vs
Version 2:
The phone buzzed. A text. Marie: “I miss you.” Bob’s eyes watered a bit as he tapped the 3 dots, and hit ‘Block.’

I bring “Show, don’t Tell” up because, although it’s been embedded in my brain for the past ~20 years, a recent beer-night conversation with a friend (Hi Branden!) reminded me of those words. He was talking about the power of a good demo. Having tech to show off is simply more compelling than a simple conversation.

If you want to try something new, or convince someone of your idea, remember Branden and his idea. Show, don’t tell.

A developer I’ve been coaching finally executed a great demo on Angular for our weekly developer meeting. She spent nearly 3 months learning Angular. Her demo contained a soup to nuts implementation of a site, including tests, test coverage, a CI / CD pipeline deploying the site all the way to an azure site. She did this demo over the course of 45 minutes.

I was thinking about what sort of conversation it would be if she didn’t have the full demo. Maybe 5 minutes? Maybe she’d have been overruled, or even redirected to another technology.

But a full demo? She had the whole group listening.

Developers – Make Your Own Metrics

Writing software can have a bit of a pile of metrics to pay attention to. I especially hate being held toward measurements I cannot get control of. One of the worst offenders can be the ‘Story Point.’

The Problem of Story Points

The story point starts with the best intentions. It gives a way to for a team to build consensus about how big something ‘feels’ without the burden of a deadline. Project managers can get a general gauge of velocity, and an idea of how long a project will take to complete. But there are some glaring holes.

First, there is no baseline for a story point. What’s a 1? Without a definition of the base, what does it mean when a team estimates something at an 8? Is an ‘8’ in fact 8 times bigger than 1? If not, what’s the value of a velocity ‘sum’? If you can’t trust 1+1 to equal 2, the fact that your team got 35 points done in a sprint is meaningless.

Second, in my day-to-day developer role, I can only minimally impact the larger measure of velocity with story points. My largest impact is simply showing up for work. In effect, velocity largely measures who was on vacation for a given week.

Metrics I Care About

Things that get measured, get improved.

There are plenty of things I can demonstrably impact as a developer though. I can write more LOC, or less. I can measure test case counts and the code-coverage of those tests. I can measure the complexity of functions and classes. I can measure the depth of dependency usage, and the number of interface implementations. I can count external dependencies, or compiler warnings. I can do stupidly easy stuff and count the number of ‘.Result’ calls on async methods. (Quick tip, your target is 0.)

It comes down to a issue of my own design though. The trick is to decide what that design is, and how to measure it. For my own aesthetic, I prefer the following:

  • Small code, thoroughly-tested, released often.
  • Code which is apparent in purpose and function.
  • Code with minimal external dependencies, which can be quickly replaced when warranted.

These are my design preferences, and having them help lead me towards the metrics I care about.

Small code, thoroughly-tested, released often = Cyclomatic complexity + Unit Test Coverage * Count of the number of deployments. These are simple numbers I can get out of build tools, and can ‘fiddle with’ right there in my editor. I can target small commits that are easily released to boot. I might not be directly able to control the release schedule, but I can target code that CAN be released often.

Code which is apparent in purpose and function = Average function length / Average class size * Average length of time commits are in code review. Again, I can fiddle with function length and class size directly in my editor, and I can make smaller commits / review sessions. I can do this every day to improve these numbers.

Code with minimal external dependencies = Count them. Did I install a Nuget package that came with 6 dependencies? Is there a comparable package that only has 2? If not, can I make one? If I don’t have time, can I minimize the surface area of that package? All of those items are directly under my control.

Communicate, Communicate, Communicate

Since I have my design aesthetics and metrics that show them, I can use them to communicate value and even push them further beyond story point as a measure of value. Some examples:

PM: We only completed 25 story points this sprint. Last sprint, we got 32. 😦
Me: We improved our test coverage by 28%, and last sprint, we had only gone up 4%. Our system is more robust against failure.
or
Me: We released 7 times this sprint! Last sprint, we released 5.
or
Me: Our average function length decreased by 8.5 lines, and our cyclomatic complexity stayed the same. That means our system is easier to work with for the next sprint!

Will my PM always understand these metrics? Probably not, but then my job is to get involved and communicate my values!

I might have to compromise. You don’t get to win everything, but having your principles backed with hard numbers is a much better way to win something and exercise some authority on some of your work.

I would rather be a stakeholder in what I am building than a cog in the machine.

Developers – Know Thyself

I am not suggesting that we change everything about story points or project management in a software project. There are better minds than mine on that. However, developers should do everything they can to decide how they want to write their code, and how to measure their improvement. Be regular, diligent, honest and thorough measuring your work. It is the best way to improve what you actually care about.