complexity and correctness

into the deep

I always have to use the term software engineering with a little tongue-in-cheek. It seems software isn't engineered so much as acreted. For all this, there emerges an enormous amount of accidental complexity in the majority of long-lived software projects, especially those that are solving business problems day in and day out (as opposed to those projects that seem to take a more leisurely, disciplined, or even academic attitude).

I recently changed employers and now find myself staring a huge and complex software system in the face on a daily basis. These are my attempts to come to terms with this system and better understand how my practice of computing zen needs to evolve to be able to interface with this system in a positive way.

from chaos came complexity

Software can be complex for any of three reasons:

1. It solves a complex problem (either mirroring a business problem or a general issue in computing, e.g. scheduling)
2. It is designed in an overly clever way
3. It accumulates complexity over time, i.e. accidental complexity

My new gig has me neck-deep in a system that has a fair amount of all three types of complexity. There is a lot of business logic that's complex in its own right, but there's plenty of cruft that's crept in over the years, much of it in neighborhoods where it doesn't belong, and I've seen more than one instance so far of completely unwarranted cleverness.

clarity brings order

The complexity that comes from the problems you're trying to solve is unavoidable. The rest of it, if you are in control of the project, can be avoided with a clear head, deliberate design, and careful planning. However, if you're coming on the scene late, there isn't a lot you can do up front -- you have to make your design philosophy clear and hope that others working on the project are receptive and that there's room in the process for the movement you're advocating.

At a certain level, correctness is relative to the business. But if you take a step back there's almost always a clear gradient that points to the proper way to do things. As a developer who strives for software engineering to really merit being called as such, I try to seek that wherever possible.