Black Sheep Code
rss_feed
a bridge

I think there's a tendency of software developers to think of ourselves like civil engineers building bridges, building these well designed perfect structures, like a bridge, that will stand the test of time.

Well OK, maybe it's not quite that simple. Software engineering as a discipline is in its infancy - civil engineering has thousands of years more experience on it. It's the norm of software to be continually evolving, having additional requirements etc, where a bridge typically is built and left alone.

Still, I think that software developers, I myself have thought this way, have this idea that 'there is a perfect code architecture for this given business problem, and it's matter of us as developer learning the right tools and techniques, and putting in the time and effort, and then we'll have nice shiny perfect bridge'.

This is turn has software developers pointing to 'it's our pile of techincal debt that is getting in the way' and 'if we were only using X tool, then our problems would be solved'.

I want to make the argument that software development is inherently a messy discipline, and outside of a small application like a tic-tac-toe game or a tutorial, perfect codebases simply do not exist.

There are a few reasons for this:

^ I do need to mention that this isn't an especially persuasive argument - if a bridge was built and collapsed, the same excuses would not pass muster. So why do we make such excuses in software engineering? Perhaps it comes down to a combination of:

Also, perhaps I'm viewing non-software engineers through a perfect lens, perhaps there plenty of frustrations in the non-software engineering space that I'm simply not privy to - what comes to mind is criticisms of car designers making the job of mechanics difficult, with difficult to reach bolts and the like.

a hard to reach bolt in a car's engine bay

As software engineers we attempt to put guard rails in to move our codebase to 'the perfect solution', thinks like:

The point I would make here is that while these tools and techniques will help us have a more usable codebase, it's not a matter of collecting the right set of tools, techniques and convetions and boom you've got yourself a perfect codebase.

You could collect the perfect set of tools, techniques and conventions, your codebase would be good for a while, but then if you left it on its own, the entropic principle would take over and your codebase would tend to chaos:

The point is - we should just accept that our codebase is going to look messy, and stop striving to get it into a perfect shape.

This isn't to say we accept a messy and difficult codebase and working environment.

Instead, we still use the same tools, techniques and conventions, but with a shift in perspective - instead of striving for a perfect codebase, we're aiming to contain and compartmentalise the mess.

For example:



Questions? Comments? Criticisms? Get in the comments! 👇

Spotted an error? Edit this page with Github