There is a sounding question that I started investigating many years ago. The question is: “How to design software?“. The hard side of this question is that software design and in general software development is fundamentally hard.
As Fred Brooks suggests in his book is: “Complexity of software is an essential property, not an accidental one“. In other words software development is about managing complexity and the goal of a team is to build the illusion of simplicity.
I agree with Grady Booch when he writes in his paper that the “difficulty of design lies in disclosing which design and architectural decisions should be used to best balance the technical, economical, business, political and emotional that swirl around every software intensive system”.
To put in other terms as Booch continues: “the problem of design is NP-complete“. An optimal solution that balances forces exists but it is not computable. “So we have to accept a compromise and selecting then a good enough solution for our design problem“.
In aid of software architects that have to select the right decisions come software design principles. As dictionary says, a principle is a a “comprehensive and fundamental law, doctrine, or assumption“. Some of these design principles are quite generic and abstract that rarely help concretely a developer during the process of software design. Some of these design principles are sometimes called “heuristics” which as you can argue means “problem-solving by experimental and especially trial-and-error methods”.
There are a lot of design principles documented in books and in websites. They are important for the designer but they aren’t decisive. So I think that I can write following equation:
good_architect = Desing_Principles + Experience
Experience is the decisive factor in software development. Experience not only deals with technical stuffs but it relates with people (management , team, customer), with economic forces (market goals and pressure). To get experience you have to work on a wide kind of projects, with the right team, with the right technologies. I hope you can do this in your working life. Alas this is not particulary true for most of our careers.
To achieve experience, at least, on the technical side there is an important tool in the architect’s toolchest. The concept of Software Pattern. In general term Patterns can help by trying to identify common solutions to recurring problems. The interesting thing of pattern is that they are captured by experience. They aren’t designed upfront in a speculative way. They emerge from the field, from real software that works, from real teams.
When we speak about pattern we think at the seminal work of Gang of Four. That’s correct but there exists a larger ecosystems of software patterns that can help designers in their daily work. I tried writing a catalog of patterns in literature. The same has done Grady Booch in his Handbook of software architecture.
(pattern catalog – click on image)
 |
Pattern reading is an important activity for every software architect which hasn’t a valuable experience. I think that pattern studying is an important activity in any computer science curricula. Students can learn a lot about software design and architecture without waiting to hurt in the war’s field of a software development job.
In the last few years a lot of software intensive systems have been developed and put in production. Most of them was based on opensource projects. There is a lot of code hidden in opensource projects that claims to teach us design solutions, architectural patterns, idioms or naïve application of existing patterns and a set of principles and practices.
For my Ph.D thesis I don’t want to study theoretical and speculative academic stuffs. Inspired by the great and motivating work of Grady Booch with his handbook of software architecture, I am going to start a study of design solutions applied in several and concrete opensource projects with the goal of recovering architecture and mining new patterns or combination of existing ones.
Write me
Profile
