The Fundamental Software Design Problem

The most fundamental software design problem, that this the the most important problem which underlies all design decisions, is:

Choosing the right amount of abstraction

Say you're starting a brand new project that you don't have any previous experience with.  What sort of architecture should we apply?  We have a lot of choices, some listed here, ordered in increasing complexity:

• SmartUI
• MVC w/ Active Record
• Ports and Adapters
• SOA
• CQRS

For some problems just a glance is enough to know it needs a more abstract and complex solution.  Equivalently, some problems quite clearly should be as simple as possible.  But most problems lie somewhere in between.  And generally there's really no way up front to know exactly where on the complexity scale it will lie.

Worse still, in a large enough application different portions of the application might be more or less complex.  Some areas could be simple crud with no logic, while other areas involve heavy data processing and complex workflow and queries.

And even worser, this is a moving target.  If I had a dollar for every time something I thought was pretty straight forward became much more complicated either because of changing requirements, scope creep, or just misunderstanding...  Well, I'd have quite a few dollars!

As I see it, there are basically two strategies for dealing with this problem:

1. Start as simple as you possibly can, and evolve to more complicated designs as things change
2. Start slightly more complex than may be strictly necessary so that it's easier to make changes later

I would expect people from the Agile and Lean communities to balk at the very mention of this question.  They'd probably bring up stuff like YAGNI and evolutionary design.  And I agree with this stuff, I agree with it completely!

But I also think boiling frog syndrome is a real thing.  Even a great team with the best intentions can easily find themselves stuck in the middle of a big ball of mud.  That's just life.  Little things change, one little thing at a time, and you do "the simplest thing that could possibly work" because hey, ya ain't gonna need to do a big overhaul now, this will probably be the last tweak.  And next thing you know, everything is a tangled mess and all your flexibility is gone!

To add insult to injury, when you find yourself wanting to do a significant refactoring to a more abstract design, it's frequently your unit tests that are the primary problem spot holding you back.  Those same tests that were so useful when you were building the code in the first place are suddenly locking you into your ball of mud.

I can hear you now.  You're looking down your nose at me.  Huffing and puffing that if I'd had more experience it never would have come to this!  If I'd just listened to my tests, the ball of mud wouldn't have happened.  If I'd just understood the right way to build software!  blah blah blah.  Sorry, I don't care.  I build real software for real people with a real team, I'm not interested in idealism and fairy tales.  I'm interested in practical results!  I'm interesting in making the correct compromises to yield the best results while constantly striving to do better!

And that's ultimately my point!  No matter what design I start out with, I want it to allow me to strive to do better.  If the simplest thing that could possibly work is going to be hard to evolve into something more flexible, that's a problem.  Accounting for change doesn't necessarily mean doing the simplest thing, in some cases it means doing something a little more complicated, a little more abstract, a little more decoupled, or a little more communicative.

If this ticks you off, please come argue with me on twitter!