Category: Software Architect

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. Over time, a good solution to the right challenge will probably outlast all others.

Simple rules
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. If you had to do it all over again, you would probably do it differently. 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.

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.

Kristen Nygaard, father of object-oriented programming and the Simula programming language, used to say: Programming is learning. Accepting the fact that programming or more precisely software development is a processes of discovery and learning and not a process of engineering and construction are fundamental to bring software practices forward. Applying the concepts of traditional engineering and construction on software development does not work. The problems have been documented and commented upon by leading software thinkers for more than 30 years. As an example, In 1987 Fredric Brooks JR stated in the “Report of the Defense Science Board Task Force on Military Software” that the document driven, specify-then-build approach lies at the heart of so many software problems.

So where should the software industry go and look for improving their practices? What about the industries involved in production of sophisticated mass-market products such as cars, pharmaceutical drugs or semiconductors?

Lets take a look at the car industry. When planning a new model, the first thing is to choose a concept or archetype. It‘s primarily an architectural positioning mechanism. BMW X6 is an example of a new concept that combines the properties of a SUV and a Coupe into what BMW calls a Sports Activity Coupe. The thing is that before you can purchase a new X6, BMW has invested thousands of hours and millions of dollars in both its vehicle and manufacturing design. When BMW receives your order, one of their assembly lines will kick in and produce your customized version of the X6.

So what is the lesson learned from this carmaker scenario? The important lesson is that the making of a new car involves two processes: The first process is the creative design process, including establishing the required assembly lines. The second process is the manufacturing of cars in line with customer specification. In many ways these are the processes we find in the software industry as well. The challenge is what we put into the terms.

In the article ?What is software design?? Jack Reeves suggested that the only artifact of software engineering that satisfied the criteria for a design document, as such document is understood and used in classical engineering, is the source code. The manufacturing of the software is automated and taken care of by the compiler, build and test scripts.

By accepting that carving out source code is an act of design, not an act of construction we are in a position to adopt useful management practices that are proven to work. Those are the practices used to manage creative and unpredictable work such as developing a new car, a new medical drug or a new computer game. We talk about the practices of agile product management and lean production such as SCRUM. These practices focus on maximizing return-on-investment in terms of customer value.

For the software industry to capitalize on these practices we must remember: Programming is an act of design, not an act of construction.