Why Finishing Software Is Hard. And What To Do About It.

Yes, The Last 10% Is Hard.

The Last 10% Is Hard

“The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time”

— Tom Cargill, Bell Labs (ancient software wisdom — if you know an Agile equivalent, I’d love to hear it)

The last 10% of a software project, is hard. It just is.

There’s nowhere to move the deadlines — time’s up. The thing you are building, which used to feel like a set of well-understood building blocks, now streams towards you in an endless river of barely connected details. UX wording needs to be exactly right; reliability, which was “good enough for beta” now needs to be 100%; that niggling bug everybody has been working around for weeks needs to go away, today; a feature that you thought worked great is missing something — not clear what it is, but it is clear that the beta users have to have it; the CEO has an idea and…

The more you do it, more you learn to pattern match on traps you’ve fallen into in the past. But I’m not sure anybody ever learns enough to bring their projects into the final deadline smoothly and without stress. (Maybe you do — if so, let everybody know your secret). There’s something more fundamental going on here.

Why Finishing Any Creative Project Is Hard

We think of software as “engineering”, which gives it a mechanical, logical feel. Some of it is. But mostly, software is a creative act. Parts are knowable: they are understood libraries, or built to known templates, but the most interesting, the coolest parts, aren’t.

Creating those pieces is more like writing — the engineer (coder? writer? yes, writer), is translating a set of abstractions (business requirements, wireframes, architectural outlines) into expressions of those ideas in language.

And like writing (or painting, music, sculpture — anything), we discover software as we make it. We can sketch, plan, write user stories and build prototypes, but however diligent we are, those are representations of the thing, not the thing itself. We can only discover the thing itself by building it. We accept this for writing novels (who would ever publish a first draft?), but we are less comfortable applying this to software. For some reason, software is still “engineering”, and “engineering” is seen as precise, knowable (yes, even when we’re deep into Agile and Lean). It isn’t.

The last 10% is hard because we can’t know what the “last 10%” is until we get there. That’s the nature of the creative process. All the final details, the hidden difficulties, the polishes that make a piece of software (or a novel, or a song, or a sculpture) brilliant don’t fully reveal themselves until the rest of the structure is built. The software “tells us what it wants to be” — we have to build it to find out.

Why People Don’t Like Finishing

And then there is the uncomfortable fact that a lot of people don’t actually like finishing things. We do like being finished, which is different. It’s that lovely sense of having something behind us, of completion. We really want that. Especially during the long “last 10%” which is so much more work than we expected. We badly want that lovely hit of dopamine, that change, that relaxation, that comes from being finished. So, as humans, we gloss over details, try and ignore user feedback, hope that a patch to a reliability problem will hold, and generally avoid the hard truth that it isn’t done yet.

And then there’s the fact that the world is eventually going to see our work, and judge it. It’s scary. So we put off exposing it to the outside world, because the outside world is going to tell us what it thinks (whether the “outside world” is beta testers, your investors or your buddies at the co-working space). It’s the “nah nah can’t hear you” approach: as long as we don’t let anybody see it, we won’t suffer the possibility that it isn’t done yet.

We want the answer to the question “is it beautiful?” to be “yes”. And for quite a while, the answer will be “no, not yet”, or “no, not even close”. Scary to hear. So we’d rather “polish a few things”, or “just do another pass”, or “get the design exactly right”. Anything to avoid the bright lights…

A Note on Agile and Lean

Agile and Lean help. The Agile and Lean models are process structures which help us model fundamentally creative and fluid business of building software. By emphasizing that software isn’t done until it’s done, that iteration is a fundamental methodology, not a bug in development, and that the sooner software is exposed to real use the better (among many other things), these frameworks more closely match how people express themselves in code. (And it’s worth reminding ourselves that a software project is only that: people expressing themselves in code).

But all frameworks can be hot-wired. The definition of “done” can be fungible. Features that are “hard” can mysteriously end up way down the story list. Judgement, management and leadership still apply. Finishing is still hard.

Getting Finished — Management

Accomplishing anything worth doing with a group of people means managing: tracking details, setting deadlines, assigning tasks — building and checking off lists. Finishing a software project means lists. Long lists.

There’s no real magic here. Your job is to hold the truth up to the light, and that means you just have to track everything: the truth is in the details. All of them.

Everything. Bugs, issues, opinions, performance, you name it. Anything you don’t track will be incomplete or dropped. Could be you’ll get away with it, but eventually the habit of producing incomplete results will catch up with you and your team. There are plenty of tools for tracking, and entire books on how to do it well. Find one, and do it.

It will feel like overkill to track every single thing. It’s not. It will perhaps feel overwhelming. You may feel you are being unreasonably stubborn, or too detailed. You’re not. You are providing a vital service to your team to help them achieve the difficult and rewarding task of finishing something difficult.

Eventually the lists will start shrinking rather than growing. And you will be close to being finished.

Getting Finished — Leadership

So you’re managing. You’re also leading. Your role is to provide the energy to help your team through the barrier of not wanting to see where things stand — to see that yes, you’re not finished yet but you will be.

Your leadership role is to have courage and confidence that what you’re building will work, and that each detail, bug and nasty little issue taken care of is a step towards finishing. Really finishing.

So you celebrate wins. You celebrate finding bugs. You dig mercilessly into performance reports. You ask questions about quality levels. You show progress daily, weekly and monthly, and you let your people know what yes, it’ll be finished, and yes, it’ll be great. You know that, right? No? Well, what do you need to fix?

Finishing Is How You Leave Your (And Your Team’s) Mark

Pieces of software I had a hand in building over twenty years ago are still being used by thousands of people (hi, FrameMaker!). Projects that I thought at the time would kill me and the people working for me helped allow our company to go public (hello — and goodbye — Director). I love the fact that we built them. I love that people are still, to this day, working in careers that are possible because of them. The act of actually finishing them? Hard! Unfun. Not sure I loved it, but all of that intensity was necessary to bring them into the world, and I’m glad they are there. They are parts of my mark in the world.

Finishing a challenging, creative task is one of the harder things human beings can do. We are wrestling something out of the realm of thoughts and ideas into the real world. We have to see, and come to terms, with all of it — every detail, every flaw. To do that requires a constant focused, concentrated effort.

If you are leading software people, your job is to help your team get into that uncomfortably intense pocket of growth.

And then you’ll be done. And you will have added something to the world, something that you, and the people that work with you, have created.