Embedded Files
According to Robert Martin,
The word “architecture” is often used in the context of something at a high level that is divorced from the lower-level details.
The “design” more often seems to imply structures and decisions at a lower level.
Let's understand with an example.
Architecture
It is the shape of the home, the outward appearance, the elevations, and the layout of the spaces and rooms.
Design
Design includes where every outlet, light switch, and light will be placed, which switches control which lights, where the furnace is placed, and the size and placement of the water heater and the sump pump.
In short, all the little details that support all the high-level decisions.
Architecture and Design in Software
Those low-level details and high-level decisions are part of the whole design of the house.
In Software Design, the low-level details and the high-level structure are all part of the same whole.
They form a continuous fabric that defines the shape of the system.
You can’t have one without the other; indeed, no clear dividing line separates them.
All decisions from the highest to the lowest levels should be taken in order to form a good System.
What is the goal of those decisions?
The goal is to minimize the human resources required to build and maintain the required system.
The measure of design quality is simply the measure of the effort required to meet the needs of the customer.
If that effort is low, and stays low throughout the lifetime of the system, the design is good.
If that effort grows with each new release, the design is bad.
Case Study
This case study is from book "Clean Architecture".
According to the book, Case Study includes real data from a real company that wishes to remain anonymous.
Figure 1: Growth of the engineering staff
x - Major Release
y - Number of Engineering Staff
Figure 2: Productivity over the same period of time
x - Major Release
y - KLOC
Figure 3: Cost per line of code over time
x - Major Release
y - Cost per LOC
Figure 4: Productivity by release
x - Major Release
y - Productivity
Figure 5: Monthly development payroll by release
x - Major Release
y - Monthly Payroll
Comparing two Charts
Comparing Figure 5 and Figure 2,
That initial few hundred thousand dollars per month bought a lot of functionality—but the final $20 million bought almost nothing!
What’s Wrong?
The lie used by many developers, “We can clean it up later; we just have to get to market first!”
The things never get cleaned up later, because of market pressure.
Getting to the market means, you have got competitors on your tail and you have to stay ahead of them.
The fact is making mess is always slower than staying clean.
Experiment using TDD
Work on the latter days is completed more quickly than the former days.
Notice also that work on the TDD days proceeded approximately 10% faster than work on the non-TDD days.
The slowest TDD day was faster than the fastest non-TDD day.
Conclusion
The only way to go fast, is to go well.
Take software architecture seriously, you need to know what good software architecture is.
To build a system with a design and an architecture that minimize effort and maximize productivity.
One need to know which attributes of system architecture lead to that end.
Page updated
Google Sites
Report abuse