Boring code is boring, and maintainable

One of my current colleagues has the following written in his “Looking for” section of his professional online profile:

Please no standard Java Stack

As i have read this i thought “hell yeah, i think he is bored and need something exciting to do in his every day business.”

I was kind of right.

Fast forward a couple of weeks. A long discussion about the architecture of our current project concluded in a highly risky compromise.

Because we (thought) to have a complex problem we turned our ears to the one with the complex solution.

There was whispers of a less risky ways, but in the heat of the discussion they where turned down. Also because we believed in the people with the “most experience”. And also, nobody wanted more discussions, but solutions.

Fast forward a couple of months. There is a decision in the making, about a problem we have. The solution could actually be very easy and fast implemented. But now there are discussions about “industry standards” and “bigger fishes then we, do this since centuries and it works”.

So, what has this all to do with boring code?

Everything of this discussions resulted in a architecture solution which is actually very complex, complicated, build with visions of “could be needed in the future” and, in fact, highly not maintainable.

(This was not my impression alone, but the impressions of multiple heads linked directly or indirectly to the projects.)

Why is it not maintainable? Because the code, and the architecture itself, where build about things that could be happen, with assumptions that didn’t happened.

Because the decision maker where sure that with one hard hit the problem ahead is solved, but forgot that they also are just humans and can’t think about everything.

But you don’t always need complicated solutions for complicated problems.

And when it evolved in being complicated, review it and break it down in boring structures again.

Because here’s the thing: boring code is maintainable. Readable. And most of the time compatible with other developers. Which is a good fail safe in a team of developers.

So, how do we know if our code is boring? One of the signs is, if another developer understands what happens without a long study time of the code itself.

The other is, if it is easy testable. Easy means, without a phalanx of mocks or setups for simple unit tests. If you need a bigger setup for mock data for a simple unit test then the tested structure has code, then something could be wrong.