Why do we need software architecture?
One of the most important questions that are raised during the development of a software projects is the economic benefit of software architecture. The question is commonly asked by business people, the owner of the software, and even by software developers.
When you are developing software product without any design at the beginning everything usually goes very fast. You are working on implementing concrete functionality and clients are satisfied because they get a working prototype in a short period of time. When you are developing software with architecture it initially takes more time, since you need to spend some time on analysis and design of the system architecture.
For example, if you give them two versions of the same software, one without and one with software architecture. Version without design cost $1000 less than the version with design, because it is developed faster. When you take a look from a business people standpoints, it is clear that the first option without no software design is the winner. They get cheaper software in less time.
Software quality
The main reason for that is that we have internal and external quality of the software. External quality is something that is clearly visible to business people, like stability, good user experience, pleasant user interface, and so on. While, internal quality is something that is only visible to technical people and that is ability of the software to change and react to the needs of the market.
So in the short term it might look like software with no design is the winner, but in the long term it’s not. In today’s dynamic time where changes are happening almost instantly it’s easy to imagine and find examples where companies got in trouble because their software is hard to change and maintain. They were not able to react on the market needs and they lost their position in the market. This is the main economic benefit of software architectures, in the long term you will become faster than your competitors, because your software is well organized and you can easily add new features and get a competitive advantage. Software development cost become smaller and you are able to develop faster.
In my professional career I was a few times in a similar situation. The projects that I implemented for some companies were complex and on the market happened some big changes and we were not able to react to them. That company lost its position on the market and I lost a valuable clients. Another example is when I worked as a contractor for a company that had a large project with a lot of developers and without software architecture. They had tough deadlines and they tried to keep up with them while constantly adding new developers to the project. Of course, they failed, because the software was hard to change and maintain. Days were required to make some small change or to add a new feature. I am quite sure that those feature could be added within a few hours with correct software architecture. This also lead to bad atmosphere in the team, because developers could not finish their tasks easily.
Design Stamina Hypothesis
Everything that I wrote above is defined by Martin Fowler and it’s Design Stamina Hypothesis. So, I will not reinvent the wheel and I will add his graph and quote a few sentences from his blog.
The pseudo-graph plots delivered functionality (cumulative) versus time for two imaginary stereotypical projects: one with good design and one with no design. The project that does no design expends no effort on design activities, whether they be up front design or agile techniques. Because there’s no effort spent on these activities this project produces function faster initially.
The problem with no-design, is that by not putting effort into the design, the code base deteriorates and becomes harder to modify, which lowers the productivity, which is the gradient of the line. Good design keeps its productivity more constant so at some point (the design payoff line) it overtakes the cumulative functionality of the no-design project and will continue to do better.
The full article can be found here.
If you read that article you will see that this “Design Stamina Hypothesis” is conjecture, since it is not based on scientific facts, because Fowler says that is hard to test it and because we can not easily measure productivity. He says that this is axiom based on the experience from his personal and work of his colleges.
Conclusion
The main goal is to identify the design payoff line and decide if software architecture is required for your project. So, if your project is small there is no need and sense to lose time for software architecture. Martin Fowler suggests that the design payoff line is usually much lower than most people think: usually weeks not months. If you are developing a large software product in a team with a lot of developers there are obvious advantages of software architectures.
I want to emphasize how important it is that you make software architecture design based on only confirmed features from the client. It is very common that the client is not quite sure what they need and you could easily lose time making something that they do not need and want. So, iterate over your project as fast and as often you can.
I decided to write this article because I experienced similar problems in my career and this hypothesis could be a good selling point when you are trying to justify software architecture to business people.
If you are interested in topics like this about development, you can follow me on Twitter @Zookey90.
No Comments