Avoiding Impedance Mismatch

ImpedanceMismatch is a nasty problem that affects the lifecycle of software systems. Sometimes the problem crops up during development, sometimes after a system has been in production for a couple of years. What steps can we take, during design, development, and deployment, to assure that the rate at which we can change software is acceptable within the context of the rate that the corporation is changing?

-- JeffChapman

Sometimes though, ImpedanceMismatch is left in a system intentionally, as it allows a system to eventually become obsolete. This enhances JobSecurity.

That's a Holy Grail you've asked for Jeff. The usual modularity helps a lot, but entropy gets you eventually. The only approach I know is to have a big bag of tricks to handle all eventualities including when the horse is dead.

Here are a few ideas...

Evaluate development languages to determine which are appropriate for various anticipated system lifecycles
Evaluate vendors for continuity of business operations in accordance with your own company's plans
Always start with the simplest design - as a project progresses, design always gains complexity
Have management commit to a StrategicPlan for the business before investing man-years of effort on system development

Do Refactoring. (See WhatIsRefactoring.) Look at ExtremeProgramming. There is no technical reason that any system should die of entropy just because lots of changes are made to it. It is possible for system structure to improve under maintenance -- you just have to know how to do it.

Eh, slow down the rate at which the corporation changes. Programming is hard work and takes lots of time, man.

Seriously though, if members "in-the-know" from the I.T. department sit on the BoardOfDirectors? of the company, then they can enlighten managment to the constraints imposed by changing the systems. If I.T. managment doesn't have this power, however, then the continual competitive demands of marketing will squash successive I.T. managers one after another.