Today at work I had one of those lengthy, impassioned discussions with the senior leadership of my company – the sort of discussion that makes me love working at a startup. We talked about our wishes for the product and our worries about where it is now, and we ended up with a list of urgent stuff that I suggested would take about ten months to accomplish.
“Really?” asked the CEO. “I thought some of this stuff would be easy.”
I reflected on this for a while after the meeting, trying to think of ways to describe why even the easy stuff takes much longer than she might think. A kind of flow chart started to develop in my head. At the beginning of the flow was the request for some “easy” new feature – something, say, that a business person could describe in three sentences. Then my imaginary flow chart split into basically two possible approaches for getting it done:
In one approach, someone (me, at my company) writes a detailed spec – enough so that an engineer knows exactly what the feature needs to do, and how to know if it succeeds in doing that. Writing such a spec is not done in a vacuum. Even with the “easy” features, there is some back and forth with the business, as well as the engineers. Then there’s often some work the visual designer has to do to make sure it looks right. All of this can easily take a couple of weeks – especially since working on this spec isn’t exactly my only job – and that’s without any concept testing or customer input. So, a couple weeks of spec-writing happen, then engineering begins. Let’s imagine an engineer has estimated that the feature will take him three days to build. He’s not necessarily factoring in the meetings and other distractions that will disrupt is engineering time, and he’s definitely not factoring in the five bugs he’ll have to urgently fix. All of this can conspire to push a three-day feature beyond the cutoff for the sprint it’s supposed to be a part of, and if it winds up overflowing into the next sprint, even by a day, that’s three more weeks that customers will have to wait. This is how an “easy” feature can take two months to find its way into the product – not from the time it was conceived, but from the time that work actually started. In my flow chart, I labelled this approach “getting it done right.”
I called the other approach “getting it done soon,” and the main difference is in the spec stage. In this approach, I don’t write a very detailed spec, there’s not much upfront back and forth with people, and I don’t get the visual designer involved. I write down just enough so that the engineer can start to work, and I make myself available to the engineer while he’s building the thing, so that we can flesh out the requirements together on the fly.
Once I laid these two approaches out in my head, I realized I’d basically described waterfall and agile.
I also realized that there’s a huge misconception among business people about agile development, which is that it’s faster than waterfall. “Getting it done soon” is not a good way to describe it at all. You might release something sooner than you would with waterfall, but then you inevitably have to keep building on it and enhancing it, release after release. Not to mention all the new bugs you now have to fix. Bottom line is, the whole thing is ‘done’ in about the same amount of time with either approach.
I should also mention that this version of agile is far from optimal. Even with agile, you should have well-written user stories that include good success criteria before engineering begins, and there should be a collaboration with the developers along the way, instead of just a handoff of requirements.
I thought about all this on my way home from work today, and after I got home I read an amazing couple of blog posts one of our engineers sent me:
The first is, Coding, Fast and Slow: Developers and the Psychology of Overconfidence by someone name Dan Milstein. There are so many nuggets of insight in this post, I won’t attempt to summarize it. It’s a total must-read if you want a wise perspective on why stuff takes as long as it takes, and much longer than anyone thinks it will. I like it better than this Quora answer to the same question, which is also fantastic.
The other post, No Deadlines For You! Software Dev Without Estimates, Specs or Other Lies, is Milstein’s (sort of) solution to the problem. I like to think I follow his strategy in the sense that I have a compulsion to make sure I fully understand the problem we’re trying to solve before I go too far down any solution path. But my way of pushing things back upstream to the ‘problem’ too often feels like pushback. For me, Milstein’s post provides a good template for asking the same kinds of questions while keeping things positive.