I haven’t posted for a while, but it’s not because anything has slowed down. I actually have more going than I can handle. If all goes well, you’ll see a couple of exciting announcements from me very soon. I wanted to take a brief moment this morning to post an observation that seems to hold across all software development, and often into other life endeavors. The last push is always the hardest.
I’m well into my marathon training. I’m pretty sure I’ll finish now. I’ve run 17 miles twice now, and 20 once. I have one more long training run, of 21 miles, before the main event in Memphis on December 2, I think. 17 miles yesterday was remarkably easy. My body has turned a corner, so I can sustain a much more aggressive pace than I could before. My first run was 4 miles, and I’m running 17 at a pace that’s 2 minutes per mile faster than that initial run.
But some have warned me: the first 20 miles of a marathon is the first half. The last six is the last half. I think I believe them. But as a software developer, I’m ready for the pain.
How many times has a programmer told you “I’m 90% done,” when the real answer is more like 50? I’m in the "last 10" of a project that should be one of the larger public-facing Rails sites built, if all goes well. The project is about two months old, and we’ve done with four what others said they could not do with a team four times as large. But I’ve seen the drill. The details take time. So I made a budget of a month and a half for alpha and beta. Why does this always happen?
- The happy path represents little more than half of the overall code. Hammering out details always adds complexity to an application.
- The executable code is not all of the application. Whether you spend the rest of the time debugging, testing, or building automated tests, you need to cover your bases. Integration tests help. My team does automated tests and continuous integration—-you can’t drop code until tests pass—but some do cut corners, and we inevitably regret it.
- You need to make an investment in a critical mass of code before you encounter business complexities that make your core assumptions break down.
- Production issues take time.
All of these factors, and doubtlessly others, come into play to make those last six miles of the marathon drag on forever. But with a little experience, you can compensate. Interestingly enough, as I’ve built Rails application, this phase of application development seems to represent just about the same percentage of the overall effort.
Once we launch the public site (beta customers will come on line in November), I’ll have many more thoughts about this project. In fact, I’ll be announcing what you can do to participate in a beta soon. Until then, paddle like Hell.