One of the things I've been most entertained by as the years have gone by, is observing what things have lasted and what haven't. So many patterns, frameworks, paradigm changes, and algorithms, all argued for with passion by smart people, thinking of the long term, balancing all the known issues, have not warranted more than a yawn over the long haul. Why? What is history trying to tell us?
Pick a worthy challenge
This one is tricky for a software architect. Challenges or problems are given to us, so we don't have the luxury of choosing, right? It's not that simple. First of all we often make the mistake of believing that we can't influence what we are asked to do. Usually we can, but it gets us out of our comfort zone in the technology space. There are dragons there when we don't choose to do the right things. Time passes, we have worked diligently and hard solving the requested challenge, and in the end it doesn't matter: we didn't do what was really needed and our work is wasted.
As architects, we tend to love the problem solving aspect of what we do. We focus on making elegant solutions. We often have to expend a lot of effort to see these things through, but we are disciplined so we get it done. All this combines to be our undoing because often we might have been better off focusing on alternative solutions, to possibly alternative challenges in the first place. Over time, a good solution to the right challenge will probably outlast all others.
We say it to ourselves: keep it simple stupid. We say it but we don't do it. We don't do it because we don't have to. We are smart and we can handle some complexity and easily justify it because it adds agility to our design, because it is more elegant to our aesthetic sensibilities, because we believe we can anticipate the future. Then time passes, you walk away from the project for a year or more. When you come back look at it, you almost always wonder why you did what you did. The time you spent aligning your gray matter to that particular solution has long since passed and you've moved on to something else. If you had to do it all over again, you would probably do it differently based on what you know today. Time does this to us. It makes us look silly. It is good to realize this early and get over yourself, and really try to learn what simple means in the lens that only time can grind.
There are exceptions of course. There are complex and worthy problems that require and reward for suitably complex solutions. The trick as an architect is to understand what problems are truly worthy for anything beyond simple. Then when you realize the problem isn't that worthy, as most problems aren't, you should expend your energy on solving simple rather than simply solving.
Be happy with that old stuff
Architects love to search for the “one true way”, the methodology, or school of thought that provides the predictability we crave and the clear answers that always seem just out of reach. The problem is that whatever guiding light you have in one year will probably not match the guiding light you have in a couple of years, much less a decade later. As you look back, you will always be looking at designs that don't match your current expectations. Learn to embrace that old stuff, and resist the temptation to think you should go back and “fix” it. Was the solution an appropriate one for the problem? Did it solve the needs of the problem? Keep these as your measure, you will be a lot happier.
This work is licensed under a Creative Commons Attribution 3
Back to 97 Things Every Software Architect Should Know home page