Getting it right is another matter entirely. Getting software right is hard.
Have you worked on a project that required reading tons of code? - Many people would have, unless it's a very early stage project, or your personal project. Often times, we're forced to read a huge code base. You must have a huge task trackers and almost endless backlogs. There's not enough architecture / design mindset, from my experience.
Generally, these words are:
- "Architecture": is often used in the context of something at a high level that is divorced from lower-level details.
- "Design": more often seems to imply structures and decision at a lower level.
There's no difference between them. Low-level details and high-level decisions are part of the whole design of the house.
The goal of software architecture is to minimize the human resources required to build and maintain the required system.
If the effort (to meet the needs of the customer) is low, and stays low, the design is good. If not that's bad.
Notes: "Customer centric" - I believe the work you're doing is customer-centric, even if the software design is bad. Customer / Sales don't care how messy your code is. Bad designed software can sustain.
- Fig 1.1 Growth of the engineering stuff
- Fig 1.2 Productivity over the same period of time
- Fig 1.3 Cost per line of code over time
They're showing us a decrease in productivity. I bet you must have experienced that!
- Fig 1.4 Productivity by release
Obviously down trend.
From the developers' point of view, this is tremendously frustrating, because everyone is working hard. Nobody has decreased their effort.
- Fig 1.5 Monthly development payroll by release
It's going up exponentially.
These developers buy into a familiar lie: "We can clean it up later; we just have to get to market first!" Of course, things never do get cleaned up later, because market pressures never abate.
The bigger lie that developers buy into is the notion that writing messy code makes them go fast in the short term, and just slows them down in the long term.
Notes: Pioneer's job. A Structure for Continuous Innovation: Pioneers, Settlers, Town Planners
- Fig 1.6 Time to completion by iterations and use/non-use of TDD
TDD vs non-TDD. TDD is faster ^.
The only way to go fast, is to go well.
The story of the Tortoise and the Hare.
The only way to reverse the decline in productivity and the increase in cost is to get the developers to stop thinking like the overconfident Hare and start taking responsibility for the mess that they've made.
The developers may think that the answer is to start over from scratch and redesign the whole system - but that's just the Hare talking again. The same overconfidence that led to the mess is now telling them that they can build it better if only they can start the race over. The reality is less rosy: Their overconfidence will drive the redesign into the same mess as the original project.
To take software architecture seriously, you need to know what good software architecture is.
Every software system provides two different values to the stakeholders:
- Behavior
- Structure
make machines behave in a way that makes or saves money for stakeholders.A
Feature, Function.
(Software) was intended to be a way to easily change the behavior of machines.
From the stakeholders' point of view, they are simply providing a stream of changes of roughly similar scope. From the developer's point of view, the stakeholders are giving them a stream of jigsaw puzzle pieces that they must fit into a puzzle of ever-increasing complexity.
Function or architecture, which provides the greater value?
The business managers would go with "Function". Developers often go along with it but it's wrong.
Introducing the Eisenhower Matrix
I have two kinds of problems, the urgent and the important. The urgent are not important, and the important are never urgent.
| Important & Urgent | Important & Not urgent |
| Unimportant & Urgent | Unimportant & Not urgent |
- Behavior is urgent but not always particularly important.
- Architecture is important but never particularly urgent.
Arrange them into priorities:
- Important & Urgent
- Important & Not urgent
- Unimportant & Urgent
- Unimportant & Not urgent
Important is in the top two positions of the list, however, we tend to prioritize the #3 higher than the #2. Managers don't care about the "Important". It's development team's responsibility to assert the importance of architecture over the urgency of features.
Fulfilling this responsibility means wading into a fight ("struggle").
The development team has to struggle for what they believe to be the best for the company. So do other teams (management, sales, marketing, operations).
Effective software development teams tackle that struggle head on. They unabashedly squabble with all the other stakeholders as equals. Remember, as a software developer, you are a stakeholder. You have a stake in the software that you need to safeguard. That's part of your role, and part of your duty. And it's a big part of why you were hired.
Just remember: If architecture comes last, them the system will become ever more costly to develop, and eventually change will become practically impossible for part of all of the system. If that is allowed to happen, it means software development team did not fight hard enough for what they knew was necessary.