Compatibility, Processes, Solutions

Thursday, January 22, 2004

When API's get changed, and you're not within close physical proximity of the people responsible, you can do two things: let the problem escalate, because it's really not your problem if things get thrown arround for no reason, or go adapt your code, because that gets results much faster. The first option is a waste of time for at least half a dozen co-workers, but especially for yourself, since you need to deal with people ("Can you summarize that in an e-mail?") as opposed to compilers ("Unexpected argument: szName"), and at the end of the day (or the week), the decision is made, amidst great fanfare, to, well, get with the program. So you might as well fix the compile errors right away, and call it a day.

Sometimes adapting to changes means you'll have to update (or upgrade) your team's development region (roughly: a place in the file system, controlled by the versioning system). When such a region is shared with other teams, you'll have to coordinate, which means asking for permission, and sometimes, proceeding anyway. So when you go asking, you'll hear this:

I don't have any testing capacity available.

I was stunned. I mean, it's one thing to refer to people's unpaid overtime as "capacity"; I guess we live in an industrial age, and we use abstract nouns a lot, and somehow, this is supposed to help us going forward. But I think it's not very responsible when someone, weeks before rollout, orders to postpone the steps absolutely necessary to make the application even compile, let alone work. At some point *before* we send the binaries to our customers, the problem needs to be fixed, the sooner the better.

Oh yes, it would also be a good idea to test the application, afterwards. But if the first thing that comes to mind, in a situation where the code won't even fucking compile, is a trivial issue of assigning test tasks to someone, then this is a sure sign that formalized, methodolical, "process-based" thinking has replaced common sense. The person in question was thinking: Updating our dev region tends to destabilize it (true), and I need to make sure that everything works as before, since I'm the person responsible, and I wish to sleep sound at night.

This is angstful, security-oriented thinking: sticking "to the book", some people are obsessed with "protection"; they worry about securing what isn't even there. They're so afraid of the consequences, they don't realize the child has already fallen into the well, and no amount of rule-obedience, formalization, or paperwork is going to help.