The Developer's Dilemma

Over the past few years, I have learnt this the hard way. It's the classic dilemma a software developer faces when putting together a software design. You've got 2 flows that require pretty much the same functionality. Do you design a common layer to take care of it or do you keep it split for extensibility? I'm not talking about a small twist, assume the functional layers goes through various facades, factories or adapters. What do you do?

For set-piece software, where all requirements are laid out.. or where at least you have an idea of where you're headed.. it's possible to design your layer so that's extensible to meet future requirements. But if it's a perpetually changing application, like the one I work on, there's no way you're gonna be able to design for a change that's coming in 5 years later.. when today, you don't even know what the change is.

And this is the problem.. I find (when I review code or sit through design reviews) that people often close the doors on future unknowns by making their design too air-tight. It fits the current requirements perfectly, but it's not open to future additions. I agree that designing for the unknown is impossible but how difficult is it to ensure that all components of your layer have access to some flow differentiating parameter which can be used at a later point in time.

When I hear that something cannot be done because is a common piece of code deep within a layer that is flow-agnostic, it irritates the hell out of me.

Coming Soon: A post on code readability, my other pet peeve.