Users and Roles (Part 1)

In my last post, I pointed out that complexity is the reason why good programmers sometimes write bad code. Complexity, however, can be difficult to recognize at the time you are creating it. Let me give you an example from my own experience as someone who has written code they later regretted.

Why do good programmers write bad code?

One of the things that annoys me the most about programming is bad code, especially if I'm the one that wrote it. And I know I'm not alone, because I work with other programmers, good programmers, and I hear them say, "Who wrote that crap?" knowing good and well they wrote it themselves.

It happens to all of us. If we write a lot of code, sooner or later, we're going to write code that embarrasses us because we know better than to do what we just did. And I don't believe it's simply a matter of being rushed, or being tired, or just having a bad day. I think there's a fundamental problem that makes bad code difficult to avoid unless and until we address it.

Over-engineering

One of the lessons I've learned all too well over the years is the cost of over-engineering. It's an easy trap to fall into, because once we start to get into a particular problem, and start breaking it down into smaller tasks, it's easy to see other problems that could also be solved using the same tools. Complication ensues, because we try to write code that covers every possible use case. This violates the agile programming rule of YAGNI (you ain't gonna need it), which is a good rule for avoiding over-engineering. But there's an even broader principle that also applies here, and that's the principle of doing more by doing less.

Microservices and DRY code

We're talking architecture at work, specifically monoliths versus microservices. Martin Fowler has been posting some articles that we're talking about, including Start With A Monolith, no Don't Start With A Monolith, and Microservices Have Trade-offs. It's thought provoking, and good for hours of discussion, but in the end, all we really want is a good way to build performant, reliable, maintainable systems. And the key to all this is separation: we need to structure our code so that every moving part has all the pieces it needs, without creating any accidental and obstructive coupling between pieces that aren't intrinsically connected.