Microcosm vs Macrocosm
Just some quick random thoughts.
Like any developer, I constantly long for greenfield projects….and like most developers – and to my chagrin – I consistently find myself in brownfield (think “manure”) project-land, supporting apps of the worst order. The vast majority of those brownfield situations have come about because a company made an investment into a proprietary framework (Web Forms, Silverlight, MS-SQL-as-an-application-platform-God-have-mercy-on-us-all), and ignored the need to refactor, re-engineer and re-write (when necessary). At the bare minimum, there should have been serious thought and effort put into adapting legacy code bases to newer implementations (think “anti-corruption layer”, “adapter pattern” or whatever-pattern-du-jour seems to communicate the concept to your management). I’ve heard the litany of excuses so many times (and uttered them myself in darker moments) that my brain conjures up the image of a pointy-haired-executive-from-hell any time a discussion hints in the direction of ”sunk cost”.
The web is a classic example of how we – as a total community worldwide – are addressing the friction of legacy-meets-progress. The list of contenders is long, and the casualty count high – but a pattern consistently emerges: leveraging the mindshare of open source, and embracing open standards vs proprietary prisons best positions you for the inevitable technological curve ball. The drive for proprietary lock-in has brought us the often-spiteful differences in DOM implementations, and yet so has the push for innovation. Companies would do well to learn from the lessons being played out before their eyes in the web. While it’s not always practical or feasible for other browser vendors to implement the features of their competitors, having libraries like jQuery make it possible to navigate those differences with much less pain (example lesson: encapsulate what changes frequently or what’s beyond your control to change – at a system level). As more browser vendors adopt a feature that a rival pioneered, those using libraries like jQuery were already able to (at best) emulate the feature in all browsers or (at worst), gracefully degrade with less overhead. This sort of “change buffer” is the cartilage that should exist in all the joints of company systems.
Be warned, the longer you focus on polishing the brass of your proprietary cell bars (ahem…IE…Silverlight), the more your competitors can move past the mere differences in approach, and begin to differentiate themselves in more significant ways (Google with V8 and Chrome’s dev tools, for example). At the very least, non-technical company leadership should be aware of the long term technical debt they are taking on. Parting shot/example: if your preferred vendor encourages an architecture that tightly couples your services to your views’ implementations, then don’t complain when your architects tell you that the service layer has to be re-written to accomodate the shiny new market niche you’re salivating over.