8 signs that your architecture is causing your developers to stumble over each other

With almost 25 years of experience, as a consultant, I help organizations in the .NET space to professionalize their entire software development efforts, from idea to production. During such visits, I get to scrutinize their development practices, quality standards, design principles, the tools they use, their deployment pipeline, the team dynamics, the requirements process and much more. In this series of short posts, I’ll share some of the most common pain points I run into.

In my last post, I talked about how the (mis)use of tools and techniques can affect the productivity of software developers. Today, I want to talk about productivity again, but then from the perspective of the constraints imposed by architecture and technical design choices. Unfortunately, unless you’re a very experienced software architect, these kinds of constraints are much more difficult to spot. Often they come from dogmatic use of certain principles, practices or libraries, or simply because of a lack of experience. I’ve seen this firsthand more than once, so let me share some examples that should make you frown.

• A monolithic system has quite a negative connotation for many people. But for me, it shouldn’t mean much more than that it is rolled out as a single unit, and surely doesn’t imply a big…