Via Steve Eichert, I came across Jon Eaves blog entry on Building Alien Artifacts. The essence of Jon’s post was that it’s important for consultants to avoid leaving a client with code that is designed beyond the comprehensive capabilities of those who will maintain it – the software equivalent of “alien artifacts”. I think Jon makes a great point – it’s too easy for consultants to come into an engagement, whip out a few design patterns, and leave something that people without a lot of advanced OO experience have no hope of ever maintaining.

One way of avoiding Alien Artificats is to obey the Prime Directive – adopt a strict policy of noninterference and code to abilities of the client’s development staff. If the client isn’t ready for advanced designs, then don’t use them. That way, at least they have a hope of being able to maintain the code you’ve written after you’ve left.

Another approach is to be like the Monolith from 2001 – take the opportunity to communicate knowledge to the people that you work with and show them ways to improve their skills. Enable a few people within the client’s organization to assume your role after you leave. Take the responsibility of mentoring client developers as an implicit part of your job, and make a point of making your client’s developers better at what they do. That way, the client wins twice – they get well-designed code that solves their problem, and they get better developers on their staff.

Jon makes a good point, though. There are some organizations out there that are resistant to change. They may not be immediately ready for all the advanced processes and tools that you want to bring to the table. However, it's rare to encounter a (successful) organization that reacts negatively to improving the quality of its people.