It doesn’t take a huge amount of knowledge and skill to get a program
working. Kids in high school do it all the time.
Uncle Bob said that in Clean Architecture book. I spent 2 weeks for this book. So much knowledge was wrapped in it so I realized that I need to make a note before they come out of my head :)))
I. Do It Right
Getting software right is hard. It takes knowledge and skills that most young programmers haven’t yet
acquired. It requires thought and insight that most programmers don’t take the time to develop. It requires a level of discipline and dedication that most programmers never dreamed they’d need. Mostly, it takes a passion for the craft and the desire to be a professional.
And when you get software right, something magical happens: You don’t need hordes of programmers to keep it working. You don’t need massive requirements documents and huge issue tracking systems.
According to my previous experience, I've worked in a project where the design and architecture of the system made it easy to write and easy to maintain. But the previous version of that project was a bad thing. Code duplication, no design patterns, no OOP made it difficult to change and contained huge risks.
Goal
The goal of software architecture is to minimize the human resources required to build and maintain the required system.
The ultimate goal is always simple and easy to understand. But it requires huge effort to achieve.
Case Study
Uncle Bob gave us a case study from market-leading software products:
First, let’s look at the growth of the engineering staff
Now let’s look at the company’s productivity over the same time period, as
measured by simple lines of code
You could see that every release is supported by an ever-increasing number of developers, but the their performance has decreased dramatically. And the code was 40 times more expensive to produce in release 8 as opposed to release 1.
Do you think that is bad? Let's imagine what this picture looks like to the executives :)))
Needless to say, that is a nightmare. There is a trade-off between making software right and making it quickly.
A familiar lie
Developers have 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.
Getting to market first simply means that you’ve now got a horde of competitors on your tail, and you have to stay ahead of them by running as fast as you can. They can’t go back and clean things up because they’ve got to get the next feature done, and the next, and the next, and the next :)))
I could see it in reality, in any software companies I joined. Products always evolve and you have no time to come back and clean your shit :)))
The fact is that making messes is always slower than staying clean, no matter which time scale you are using.
So:
The only way to go fast, is to go well.
The developers may think that the solution is to start over from scratch and redesign the whole system. Some of the companies I have worked with or know of, they all had to redesign their systems after a long period of rapid development.
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 :)))
Their overconfidence will drive the redesign into the same mess as the original project.
Conclusion
In every case, the best option is for the development organization to recognize and avoid its own overconfidence and to start taking the quality of its software architecture seriously. So you need to know what good software architecture is, to minimize effort and maximize productivity.
(to be continued)
