8 signals that you don’t control your technical complexity

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.

And I’m sorry to say that there’s plenty of those around, even if you don’t look too closely. But for this first post, I’d like to focus on the challenges companies are facing while controlling their technical complexity. Not only can that cause unnecessary delays in building new functionality, over-engineering and unwarranted complexity to jeopardizes maintainability, but it also makes it harder to find the experienced developers that can handle that kind of complexity. Here’s a couple of examples of what I ran into.

• An architecture that doesn’t match the functional and technical requirements. Sometimes this happens because it was inspired by some technical hype the architect read about or picked up from visiting a popular software development conference. But I’ve also seen situations where a board of architects dictates a reference architecture…