200 OK SwatantrAI

Software architects solve a lot of very difficult problems but we also solve some relatively easy ones. What we don‘t want to do is apply a complicated solution to an easy problem. As obvious as that advice sounds it can be hard follow. People who design software are smart, really smart. The simple problem-complex solution trap can be an easy one to fall into because we like to demonstrate our knowledge. If you find yourself designing a solution so clever that it may become self-aware, stop and think. Does the solution fit the problem? If the answer is no, reconsider your design options. Keep the simple stuff simple. You‘ll get plenty of chances to showcase your talent when the difficult problems arise, and they will.

This doesn‘t mean that we shouldn‘t implement elegant solutions. It means that if we‘re tasked with designing a system that only needs to support selling one type of SKU based widget it‘s probably a bad idea to design for hierarchies of dynamically configurable products.

The cost incurred by a complicated solution may seem small but chances are it‘s larger than you‘re giving it credit for. Over-engineering at the architectural level causes many of the same issues as it does at the development level but the negative effects tend to be multiplied. Poor decisions made at the design level are more difficult to implement, maintain and worst of all reverse. Before moving forward with an architectural decision that exceeds system requirements, ask yourself how difficult it would be to remove after it‘s in place.

The costs don‘t stop with the implementation and maintenance of the solution in question. Spending more time than necessary on an easy problem leaves less time for when the complicated issues show up. Suddenly your architecture decisions are creating scope creep and adding unnecessary risk to the project. Your time could be spent much more efficiently making sure no one else is doing that.

There‘s often a strong desire to justify solutions with a perceived benefit or implied requirements. Remember this: when you try to guess at future requirements, 50% of the time you‘re wrong and 49% of the time you‘re very, very wrong. Solve today‘s problem today. Get the application out the door on time and wait for feedback to generate real requirements. The simple design you create will make it much easier to integrate those new requirements when they arrive. If you beat the odds and your implied requirement becomes a real one on the next release you‘ll already have a solution in mind. The difference is now you‘ll be able to allocate appropriate time for it in the estimate because it‘s truly required. Before you know it you‘ve got the reputation of a team that makes good estimates and gets work done on time.

From all of our experiences, including both success and failure, we learn a great deal. In a young industry like software development, disseminating this experience and knowledge is vital in helping sustain progress. What each team learns in its own tiny little corner of the world is possibly influential across the globe.

Realistically our fundamental knowledge base for software development, that is, the knowledge that is absolute and theoretically correct, is small compared to what is necessary to successfully develop a project. To compensate,we guess, rely on intuitive judgments or even pick randomly. In that, any major development project generates empirical evidence into what works and what fails. We’re gradually working through the permutations, which we want to apply back to industry as a whole.

At an individual level, we are all trying to grow and come to understand how to build larger and larger systems. The course of our careers will take us toward ever-increasing challenges, for which we want our past experiences to help guide us. Being there is one thing, but to get the most from the experience we often have to rationalize it. The best and easiest way of working through it is to attempt to explain it to another person.

The act of discussing something always helps to show its weaknesses.You don’t really understand something, until you can explain it easily. It’s only by putting forth our explanations and discussing them that we solidify the experience into knowledge.

Another point is that while we may have had specific experiences, the inferences we draw from them may not be entirely correct in the overall context. We may not have been as successful as we thought, or as smart as we wanted. Of course testing your knowledge against the real world is scary, particularly when you find out that something dear is myth, incorrect or was never true; it’s hard to be wrong.

Ultimately, we are human beings so not everything in our minds is correct; not every thought we have is reasonable. It’s only when we accept our flaws that we open up the possibility of improving. The old adage about learning more from failure always holds. If our ideas and beliefs do not stand the test of a debate, then it is better we find out now, than build on it later.

We really want to share our knowledge and experience to help the industry progress; we also realize it helps ourselves to understand and correct it. Given the state of so much of our software, it is clearly important for us to take every opportunity to share the things we know, what we think we know, and what we’ve seen. If we help those around us to improve, they’ll help us to reach our full potential.