"Done" means "launched". It isn't "done" until it is launched. It
annoys me to hear people say a project is "done... now I just have
to launch it". It isn't done if it isn't in production.
There are a few reasons for this: people think that launch is "the
last 5 percent of a project" but often 80 percent of your time will
be consumed by this last 5 percent.
Also, you aren't "done" until other people are benefitting from
your work (in business speak... "it is delivering value"). Written
code has no business value. Launched code does.
You can rig this in your favor. Structure your project as a MVP
(minimum viable product)
launch followed by a series of mini-launches, one per feature. This
way your written code stays unlaunched for the shortest amount of
time. An MVP release might be just the main webpage and placeholders
for every feature. However it forces you to go through all the
launch tasks: setting up the web servers, load balancers, databases,
and so on. These things can take a lot of time. Oh, and if there
is a separate dev team and ops team, your ops team can start
developing their runbook now, not the day before launch. This makes
operations suck less.
Which brings me to a story about wasting one million dollars...
Tom once saw a project with a plan to launch after 2 years of
development. After 1.9 years the SREs were needed for a
higher priority project. The incomplete project was abandoned and
the efforts of 5 SREs for 1.9 years was forgotten. Do the
math... that's about a million dollars that Xxxxxx wasted.
If they had launched an MVP after a few months and then kept building
on it (as
Tom had recommended) Xxxxxx would have seen some
benefit of the system. However they ignored this advice (I think someone
used the term "trouble-maker" to describe me) and they went off to
build their new system.
The goal of the project was to replace a legacy system that was
missing one important feature, then use it as a platform for
a number of new features. I don't mean to gloat, but after
my warnings were ignored, I spent a little time making a gross,
hacky, quick-and-dirty, version of the important feature and added it to the
legacy system. I launched it, and the users were 90% happy. The
2-year project was going to fill in that last 10% of happiness...
for a million dollars.
As far as I know the legacy system was used for a number of years after this.
Perhaps the success of my quick hack helped justify abandoning
the bigger project. Management had to pick a project to kill
so they could have 4-5 people for a higher priority project.
Maybe the quick hack made the legacy system "good enough"
and helped justify killing the project. Maybe this spared
some other project from being killed.
I wonder what that project was.
I'm sure the legacy system has become obsolete by now. I don't
know or care. I do, however, care that a bunch of excellent
SREs had their work thrown away... which must have been
Lately I've been thinking a lot about applying MVP-style project
management everywhere. It just makes more sense. Once you've
experienced it in one place, you can't help but want to do
it everything: system administration, relationships, home repair,
To that end I have one piece of advice: Rush to launch something...
anything... and build on it. Reduce the scope to the minimum;
avoid the temptation to add "just this one last thing" before
you launch. Do this even if it is only usable
by a small fraction of the users, or only helps a particular
special case. People would rather
have some features today than all the features tomorrow. Tomorrow
may never come.