Saturday, September 02, 2006

Good Practice, Bad Practice

Over the course of this year I've had to wrestle with an very complex legacy system. The documentation is sparse to non-existent, and the original developers are, with one exception, gone. (And that one exception's another consultant who's not always been available.)

Trying to maintain and update it has been painful. But at least, I thought, I've got quite a perspective on what not to do when architecting the replacement system, which is what I was originally brought in to do.

Oh, well. The person who brought me in left, the person who I now report to has his own ideas and team, and so -- I see all the exact same mistakes being made developing the new system that made the old one brittle and near-impossible to maintain. How depressing.

But hopefully someone can benefit from what I've learned. The what and why that I'm going to explore here is going to break down into a lot of separate lessons -- and so immediately to #1 in a list of Recipes For Failure:

1. Develop your project with people who don't care.

There are lots of ways to assure this, but a key one is using people who won't ever have to maintain it.

Pay them based on "deliverables" -- once they've handed over "it", whatever "it" is, they get paid and it's Invoice Time. Crappy or non-existent error logging? Not their problem. Inconsistent and uncommented coding styles? Not their problem. Designed to assumptions that don't reflect your development and deployment environments? Not their problem.

Fragile, brittle, difficult to maintain post-launch? Not their problem.

It's so much better if everyone's signed up to the idea from day one that maintainability is each and every developer's "problem".

0 Comments:

Post a Comment

Links to this post:

Create a Link

<< Home