Software Architecture: How Much Is Too Much?

Written by Dave Sweeton, Chief Technologist at Stout Systems

One aspect of my job as Stout's Chief Technologist—and one that I really enjoy—is reviewing code bases. I get to do this somewhat regularly; evaluating code for reusability, providing basic security reviews or giving a second opinion on implementations or architectures. These reviews are an interesting way to see different implementation styles and find new ways of doing things.

Most people don't have their houses inspected until they have visible damage. Likewise most code bases don't get reviewed unless they smell badly enough for non-technical managers / stake-holders to notice. So while I do see great code examples, I also learn my fair share of lessons in what NOT to do!

One recurring theme that I've seen over the years is a tendency to over-architect projects or make them too "enterprisey." What do I mean by that? It boils down to writing more code in the backend or middle layers than is needed to support the project's requirements. Building a two-story house with a steel and concrete structure suitable for a high-rise. Adding washer and dryer hookups to your living room, dining room, and bedrooms, "just in case."

Some projects do need big architecture, lots of components/layers/packages, and enterprise level features. Amazon and Twitter need enterprise features. A Microsoft Office or Visual Studio needs plenty of architecture. A website selling hats for cats, with tens of users per month probably doesn't need much in the way of enterprise. An internal business application likely doesn't need vast frameworks and complex plumbing.

This determination of "over-architected" is of course highly subjective and leaves plenty of room for reasoned debate. I just hope developers are having that debate—with their teams and with themselves! I think the tendency to over-architect projects is natural, for many reasons:

• Writing frameworks is fun, maybe more fun the actual work of implementing your business requirements.
• I have this great new idea or heard of a new technique that I really want to try out, regardless of or without evaluating whether it's a good choice for this project.
• Planning for the future. This project might grow bigger or need more functionality. This is a reasonable path, to a point. I've found time and time again that projects don't go where anyone (programmers or stakeholders) predict they will.
• More code equals more time, and time of course, is money. I believe (and hope) that this is not common motivation, but developers, both contract and in-house, have incentives to write more code (as long as they can make the project deadlines).

Aside from costing more up-front, over-architecting has long term costs. More code means bugs are more likely. Extra complexity makes developer spin up longer. Architecture also commits you to following certain patterns, so bad architecture can make adding new features more expensive.

One example I've noticed several instances of lately is separating the Data Access Layer and the UI… with a Web service! I'm all for separating the DAL from the UI, they should be separate projects with a defined interface. But I can't imagine why you'd want to put a Web service call in between. Web services have overhead, the objects passed back and forth must be serialized and deserialized, and even local communication protocols add delays. If the Web service is on the same server, you have no performance benefits, the UI thread will just need to wait for the results. The Web service adds coding overhead as well, if you implement a new method in the DAL, you need to add it to the Web service definition, then the Web service implementation, then regenerate the client proxy, etc. There are cases where you might want to expose your DAL through a Web API, but your UI should probably use the underlying library directly.

I've also seen desktop applications that utilized a central database, but supported running in offline mode by maintaining an XML serialized copy of the data, and updating the server via remoting calls. It was cool technology, but collisions between users were common, and the code was extremely fragile. Unfortunately, this was an internal business application and remoting wasn't a requirement. The workers used it only in the office, down the hall from the database server!

Some DAL implementations use extremely complex patterns. For example, in order to create a new method to save a changed entity to the database you'd need to: implement three classes, add methods to three separate interfaces, add two concrete implementations of those methods in separate libraries (the last was handled with a reflection library), and add two initialization/configuration statements. You would literally need to touch ten files before you even wrote code to utilize the new functionality, and that's not counting the unit tests you need to write to make sure you got this all correct!

Architecture, framework and plumbing aren't bad things. Complexity isn't bad either as long as it's necessary complexity. Projects should strive to be as simple as possible while still meeting all the requirements, including maintainability and any flexibility / future proofing that is actually required. Under-architecting is a problem as well, though it occurs less frequently in my experience and is cheaper to fix. It's a balancing act, and one of the reasons that software development is so fun!

This is a technical/business article catered to developers, hiring/project managers, and other technical staff looking to improve their skills. Sign up to receive our articles in your email inbox.

If you're looking for a job in the tech industry, visit our job board to see if you qualify for some of our positions. If you're looking to hire technical talent for your company, please contact us.

Stout Systems is the software consulting and staffing company Fueled by the Most Powerful Technology Available: Human Intelligence®. We were founded in 1993 and are based in Ann Arbor, Michigan. We have clients across the U.S. in domains including engineering, scientific, manufacturing, education, marketing, entertainment, small business and robotics. We provide expert level software, Web and embedded systems development consulting and staffing services along with direct-hire technical recruiting and placements.