Top critical review
Good But Not Great
Reviewed in the United States on June 18, 2019
I read this book to complete the DevOps picture from the manager's and the architect's point of view.
As DevOps engineer and developer with 30 years of experience, I find hard to stomach the notion supported by this book that developers should be free to choose their tools. The book goes on to assure us that the upside of doing so far outweighs the downside. I strongly disagree.
There is a thing called 'technical debt,' which is the sum of time and effort one has to pay to keep up with the tools one is 'married' to. To master a tool one has not only to learn the first version encountered but also those that follow in its evolution, and track new and discontinued capabilities during the course of the tool's life. This happens whether you learn C, Python, Java, or any other substantial language and tool in which one needs to remain proficient.
Now imagine multiple projects using languages and tools at the whim of the team members. The overall list of technologies in use would be a long open-ended list in no time. What skill requirements do you pass on to HR to recruit new talent? How many candidates will be a good match for your large list of technical requirements?
The argument in favor of such dangerous freedom is that otherwise developers may have to use tools they hate.
Choosing the staff and the tools of a project requires careful consideration. It's at this point that you choose the best possible match. Consult the team members if you will, but it should not be up to them to decide, but to the project leader. Otherwise imagine if Team A chooses Confluence for documentation, while Team B uses Office 360, and yet Team C goes for TEX. After a few years you will have a rainbow of documentation formats. How is that better than having a consistent one?
Developers like to use the tools they mastered, when not looking to learn a new one, and yes that is important, but what you do is to group people with skills pertinent to the project from the outset, so nobody will hate it.
This notion that developers should be the ones choosing a project's technologies, really broke the spell of this book for me. How could they say that, and what sort of measurements did lead to such result?