(I originally posted this on my MSDN blog.)
My new project at work has had a relatively long and, um, colorful history, as I’ve alluded to in previous posts. I think the code base is somewhere around eight to nine years old and has passed through the hands of a variety of internal and external developers, none of whom seem to have owned it for very long. Most of the the engineering infrastructure was never updated to keep up with the times so I’m now the proud owner of an application with issues that include, but are not limited to, the following:
- No automated build system
- No continuous integration system
- No branching strategy to separate ongoing dev work from hotfixes
- No ability to run the application in isolation on my local dev machine
- No proper test server environment (we have a non-production server environment but it’s locked down so only the Ops folks can access it, so it’s actually a staging environment)No automated checkin emails
- No unit tests
- No integration tests
- No ORM
Oh, of course, there’s a long list of new feature work to deliver, too. And naturally, it’s already well behind schedule. I can’t just take the next three months off to build an ideal engineering environment in which to work.
It’s rather daunting.
I don’t know about anyone else, but in situations like this I feel a strong temptation to just throw up my hands and exclaim, “I don’t even know where to start!”. It’s a classic catch-22; implementing new features is proceeding at a far slower pace than it ought to because of the poor engineering environment. There’s all kinds of friction and pain. However, the need to deliver new business value hamstrings my ability to clean up the engineering problems.
Chew, Chew, Chew
The answer, of course, lies in the old aphorism: “How do you eat an elephant? One bite at a time.” Trivially obvious, I suppose, but true nonetheless. I don’t have to solve all my problems at once. It’s ok to take small bites, as long as I keep making progress. I don’t have to have a grand plan for solving everything. I just have to have a plan for solving whatever’s causing me the worst pain right now.
My plan is to start interleaving engineering cleanup tasks with new feature work. I’m going to order the list based on the perceived ROI of solving each problem then pick them off one by one as I have time. I plan to blog about each of my engineering issues as I solve them. For the most part it’s going to be a rehash of well-worn ideas, but it’s always good to revisit them for folks who might not be familiar with them yet.
One thought on “How To Eat An Elephant”