Architecture projects are some of the most fun projects in development. Or at least they often appear that way. There is often the perception that in these projects you can fix all the little things that annoy you in your work environment. You can make it easier to roll out new features, while keeping the system more stable and easier to maintain. While this can be true, there is some risk here. In particular, many architecture projects seem to have no purpose other than massaging the egos of the developers on the project. While you might get away with this for a little while, it will eventually cause problems for you. It’s also very easy for developers to get caught up in “building castles in the sky”. Left unattended, developers tend to build more and more complex things over time – it’s one of the things most of us enjoy. While often useful within a proper context, it’s far easier to get lost in the weeds on architecture projects.

It’s also a mistake to think of architecture projects as projects that don’t have customers. An architecture project almost certainly has some indirect impact on clients, otherwise why do it? Your clients also include the rest of your team. Other developers will have to deal with the implications of your changes. QA will likely have to change test procedures. Operations may need to deal with new and different errors while deploying brand new resources to various environments. Your database administrators may deal with changes to system load. Your security team will likely have new things to audit and potential new vulnerabilities to worry about. Even groups like customer support, sales, and the like may be impacted, depending on what you are doing.

Architecture projects can be fun and can provide huge improvements to software systems, provided that they are conducted correctly. However, many developers (ourselves included at various points) get too focused on the architecture considerations we are dealing with, while ignoring the impact on the rest of the system. This can cause a perfectly good architectural solution to fail in a drastic manner. It can also alienate the rest of the team, irritate management, and actively harm customers in a way that WILL cause problems for your team, if not the entire organization. Fortunately, most of the big mistakes you can make are very easily avoided, provided that you plan ahead, use an iterative approach, and involve the rest of the team.

The post Software Architecture Mistakes appeared first on Complete Developer Podcast.