TightenThenLoosen

If you remember back in your school days, there was always that teacher that came on like a real hard-nose in the first day of school, maintained rigid order in the first month, and gradually loosened his grip on the classroom. That teacher was a genius.

It turns out that a lot of things in software work that way too. It's really easy to loosen a coding standard in the 25th week of a project, but it's really quite hard to tighten down that late in the game. You end up creating a lot of low-value rework for a lot of people. Changing the naming standard so late is really iffy if you don't have good refactoring tools, and it's unpleasant even then.

I'm working with agile transitions, and I've been reminded quite often how much harder it is to introduce testing late in a project. It is still worth doing, but it would be so much better to introduce it on day 1, before too much code has been allowed to over-couple and too much architecture is cemented into the system. Once you are multitier and have all manner of communication mechanisms and user interfaces, it can take quite a bit of finesse to bring testing into the system.

Today I was reminded again, when we had to pull together and figure out what the SUT really comprises, and how to pull it together for proper acceptance testing. The tech experts on the team estimate it will take at least weeks of hard work to collect and isolate the SUT for one set of ATs. It's worth doing, but too costly to take on at this juncture. If they had it to do over, they would have started with testing, and all of this would already have been done a little at a time in the course of the project.

If you're starting a new project sometime soon, it's a good time to establish the engineering environment so that the work can progress more smoothly. Start out a little tight, and allow loosening later on if necessary, but remember how hard it is to tighten up your engineering disciplines, practices, and environment later in the process.

!commentForm