Notes, comments and errata on Robert C. Martin's Clean Architecture
The book has 34 chapters, with a maximum of 22 pages (chapter 14). Even while involved as a programmer in a project, it should be possible to read one chapter per day, so you can finish the book in about 2 months.
Page 15, just before subchapter "The greater value". Original sentence: "Therefore architectures should be as shape agnostic are practical." Corrected sentence: "Therefore architectures should be as shape agnostic as practical."
Page 39, last sentence on the page. Original sentence: "Moreover, multiple inheritance is a considerably more difficult to achieve by such trickery." Corrected sentence: "Moreover, multiple inheritance is considerably more difficult to achieve by such trickery."
Page 105, just before subchapter "The common closure principle" Original sentence: "Indeed, the CCP and the CRP strongly define the this principle, but in a negative sense." Corrected sentence: "Indeed, the CCP and the CRP strongly define this principle, but in a negative sense."
All errata have been forwarded to Prentice Hall via the errata submission page of InformIT.
Unfortunately, it's the first chapter ("first impression") that I'm not comfortable with. Here's why:
-
Figure 1.1, page 5: is "real data from a real company that wishes to remain anonymous". Why not find an example that we can prove?
What is the unit on the x-axis? The whole graph looks too smoothly like exponential growth. However, as you'll find out later on page 7, the unit is the release number. Since releases may not occur in regular timespans, that curve may be anything but exponential.
The numbers look very clean. Exactly 600 employees for release 6 and exactly 1200 for release 8? Where do these numbers come from? They are "reproduced from a slide presentation with permission from Jason Gorman". Jason Gorman is chair of the Software Craftmanship Conference.
-
Figure 1.2, page 6: same question for the x-axis: what is the unit?
Is LOC really the right unit for measurement? Maybe the company noticed the asymptote and migrated from an implementation in C in release 5 to implementation in C#, thus reducing the lines of C code? Maybe the management added a feature, removed it, re-added it, then changed it. You may need lots of developers to do that, not changing the amount of code at all. Also UI changes can cause much effort, while the lines of code stay constant. Maybe they adapted to new legal regulations and the 600 new engineers are just there to ensure the requirements, e.g. FDA, SIL or others.
To me, the figures are too striking and too obvious. They fit the needs of Uncle Bob just too well.
-
Figure 1.3, page 7: finally, a unit for the x-axis. Now, the unit on the y-axis is unclear.
Where does this graph come from? It looks different than figure 1.1 and 1.2. So did Mr. Martin draw that graph himself? If so, where did he get the cost information from? Sure, he can just take the engineering staff and multiply by an average wage. But things may be different. Perhaps those last 600 employees were hired in India or China, where salaries are lower.
-
Figure 1.4, page 8: why does that curve start at 100%? Nobody is ever 100% productive. You always struggle with IT hardware issues, software / tooling issues, illness, etc.
-
page 8: "And yet, despite all their heroics, overtime, and dedication, they simply aren't getting much of anything done anymore.". Where does that assumption come from? How does he know the developers worked overtime?
-
Figure 1.5, page 9: that monthly payroll of $20M for 1200 engineers is $16k per employee. That's $192k per year. I feel extremely underpayed. If I just google for "average salary usa software engineer" the first results are $104k, $91k, $81k, $76k and $121k.
Sure, Uncle Bob wants to make a statement. And I have seen inefficient software development, so yes, the problem is there. However, the numbers are not reliable.