The conventional wisdom in software development is that you must always keep ahead of the alphabet soup-and-acronym marketing juggernaut that drives the technology. While I don’t disagree, exactly, I have to confess that I’m seeing an awful lot of technology that’s driven by the need of traditional software vendors to sell version upgrades and counter opponent’s product moves — and perhaps by what we geeks might find intriguing. All of which is not necessarily the same thing as a widespread, compelling need in your particular shop.
I’ve completely retooled my skill base, to be sure — four times in the 27 years since I started slinging code for a living. Sometimes a paradigm shift is compelling. I’m starting to wonder, though, whether we’re intelligently managing all the choices we have.
The mission critical application for one of my clients, good as it is, uses a mixture of direct ADO.NET, Microsoft’s old Enterprise Library, a couple of competing DB home-grown helper function libraries, plus a business object pattern that relies on typed DataSets. And lately I’m catching a faint whiff of Linq. It seems like a lot of thrashing about. If any one of these changes were so compelling we’d have found the time to cleanly convert over to one of them.
Yet this is something I’ve seen over and over, and not just in data access — rather than a coherent architecture for some part of a system, every person who works on it over the years feels obligated to urinate on it to mark their territory or to find a paying excuse to work with some hot new technology.
Any new technology has to be truly compelling — compelling enough to justify a discrete project item with a deadline that involves a proper integration, often involving eradicating some older technology. The dirty secret is that few of the latest and greatest paradigms that are feverishly churned out in the latest platform releases are so truly compelling that we can unambiguously justify the effort to properly implement them. At least not while meeting the needs of the actual users.
I don’t pretend to have a solution to this dilemma. But I can say that I’m very choosy about what technologies I explore. I make sure I’m doing a great job for my customers and I almost take pleasure in doing so without introducing more variables just because they’re cool. At the same time I don’t fear evaluating all options where an actual need exists.
Here’s a thought: maybe your next project should involve refactoring and cleaning up your existing code base without introducing any new components. Yes, for some clients this may need to be a skunk works or stealth project, perhaps done incrementally by devoting ten or twenty percent of your “official” project time to the cleanup effort. Or it may be a case of “it’s easier to obtain forgiveness than permission”. But isn’t that how a lot of this miscellaneous technology crept in anyway?
Why can’t freeing yourself from haphazard technology be at least as exciting as splicing in yet another alien component to an existing Frankenstein?
