Staying focussed on the finish

The data provider project rolls on and we’re almost at 100% of the functionality required for version 1.0. In fact, we have a few 1.1 features in there because they were easy wins and by the time we made sure that we they’d be easy to do in 1.1 we found we’d done 90% of the work for them. The task now is to avoid the numerous distractions, improve test coverage, integrate with our clients and hit the ship date.

I’ve always been someone who is focused on finishing; if you don’t ship, what was the point. In the corporate development world that can be unusual; I’ve worked with far more ‘80% done’ developers than I have with finishers. Finishing is hard, you have to stop playing with the fun bits and deal with all the nasty items on the list of outstanding items. If all you’ve done is do the fun bits all the way through the project then the list of real work is often substantial, and scary; sometimes it’s easier to avoid it all together. Investigating the new stuff is fun, and organisations do need people who can throw together a prototype using all the new toys, but they need to be aware that’s all it is and they also need to know that’s what these people are good at and not put them on key projects with fixed deadlines…

The way I deal with all this is to always finish each part of the work as I go. Everything needs to be ‘production quality’ pretty much as soon as it gets checked in. This and the ’no outstanding bugs’ mantra seem to work together pretty well to help me produce chunks of working code that can be plugged together to make a complete, finished product. Another advantage of this way of working is that even if the project is canned, at least you have some complete working code and you’re in with a chance for some reuse. If not actual code reuse then ’thought reuse’ when you need to do something similar again; you’ve worked through the complex areas and know that using technology X is possible but there are issues, or whatever. Building each part to completion also allows me to be honest with myself about where I am on my plan; and this helps.

The one thing that I don’t tend to complete as I go is external documentation; code often changes fast during the early stages of development and the need to change docs to stay in line often acts as a brake on making sweeping changes that the design requires. It’s bad enough having to change the tests but at least they support the code changes, having to change the docs too can be enough to prevent some changes happening… So, external documentation on how the code works can happen when the code stabilises to the point that change is less likely.

Distractions in corporate space can come from all angles; new versions of internal libraries to integrate, new tools to play with or switch to, new techniques to learn and experiment with, and meetings, meetings, meetings… All of these things have their place; except, perhaps, meetings ;) but that place isn’t, generally, during the production of a system that you intend to deliver on time. New techniques need to be learnt but in a controlled envioment, not by slipping your first attempt at them into the production system 2 days before code freeze… Likewise moving to new tools and components is required but there needs to be space in the schedule for it…

I’m starting to think that not only am I old and cranky but I’m also old and boring; Aim to hit the date, and then do the fun stuff.