Your software architecture is not more important that producing working software

Designing software is hard, producing internal design for the software (the software “architecture”) that both supports the user requirements and makes it easier for developers to work on the software is a real challenge.

There are a lot of “best practices” (I really hate that term), frameworks, libraries, software design principles and design patterns that are supposed to help with this challenge.

The idea behind those is that some very smart and very experienced people already solved the problem for you, they found the correct way to structure software and indentified all the pitfalls, they then wrote some easy to follow rules – if you follow those rules you will produce quality software.

Software developers are very logical people – people that are used to simple black-and-white rules (because basically that’s all the computer can understand and perform) – so software developers take those rules written by people smarter and more experienced then them and follow them religiously.

And then everything breaks down.

Every software project is different, there’s is almost nothing in common between high end graphic software and normal everyday business software or between word processors and computer games and even sometimes between normal everyday business software built for different industries.

So those software design principles, formulated by very smart and very experienced people, truly describe a near-perfect pitfall free software design – for the specific project that smart and experienced person worked on when he wrote that principle (or, in the best case, for the kind of projects that he usually works on).

And large groups of software developers all around the world, working on a large variety of different software projects, all blindly following the one true software design – and most of them hit some completely obvious limitations of that design, simply because they are doing something that didn’t exist in the project that influenced that design.

But the smart and experienced guru is never wrong, and the failing design principle always looks so logical and right (because it is right, just not for your specific project).

So those poor developers keep religiously following the one true design, building one huge patch after the other working around the limitation of the one true design, doing more and more work, making the software more and more complicated (and adding more and more bugs in the process).

And so, I have one request for my fellow software developers – never value your precious architecture more than actually producing working software that your customers can user.

If you need a global messaging system to do something that should be one method call you’re doing it wrong and should rethink your architecture.

If your design uses some design patterns that is not supported by your platform you’re doing it wrong and should rethink your architecture.

If you’re using a library for something it wasn’t designed to do you’re doing it wrong and should rethink your architecture.

And in general if you are doing something that should be easy but just hit a wall, don’t start coding some clever and complicated solution, first stop and think how to keep the simple things simple – even if you have to change your architecture.