Top critical review
6 of 13 people found this helpful
Uneven, Lacks Depth
on July 29, 2011
According to the subtitle, this book tries to define and advise on professional software development conduct. With this in mind, the title of the book sounds somewhat peculiar since there is more to professionalism in software development than being "clean", in any sense of the word.
The first chapters (Professionalism, Saying Yes/No, Coding) are the more interesting part of the book. In the chapter on professionalism, the author brings up the important concepts of individual responsibility, striving for defect-free outcome, the need to dedicate to the employer or client the time paid by the employer/client, the do-no-harm principle. Some of these topics deserve deeper treatment, however. For example, the do-no-harm principle is described in the context of structure and function of software. There is no mention of doing no harm to public, employers or colleagues (is coding and distributing a virus professional?). The author speaks about minimizing bugs, but there's no attempt to define or treat software quality in a more general way. Communication with management gets a bit digital coverage (Saying Yes, Saying No).
In the second part of the book the author gives advice on professional developers' practice. The advice is often questionable, however. A few examples:
- In the section on Test-Driven Development the author claims that the only way to achieve testability is to write tests first. While this probably works, we are not given any explanation as to why would this approach be the best or the only one. The TDD criteria could have been listed with more clarity: one needs to write unit tests first but should not write more of a unit test than it is sufficient to fail, and not compiling is failing. This begs the question whether anything that does not compile is a sufficient unit test to "allow" one to start with deliverable code?
- The author recommends constant changes to keep the code flexible, as if the code text is somehow going to become rigid if left alone. In reality, any change has more potential to introduce defects than no change, no matter how thoroughly we test, and this needs to be factored into the judgement call on whether something should be changed or not.
- In the author's words, the primary purpose of testing is actually documentation, in particular requirements and API documentation. This is in contradiction with the generally accepted view of testing as a way to uncover defects.
- Another unusual idea is that "exploratory testing", which happens without test plan, is the one that is supposed to confirm the expected behaviour of the system.
- When advising to overcome "writers' block" by finding a pairing partner, the author does not consider that this way of unblocking may effectively block the pairing partner.
The section on tools seems off-topic as the author himself explains that his intention is mainly to define his favourite tools. There definitely are tool selection, evaluation and recommendation considerations that are very relevant to professionalism, but they are not mentioned here. Yet, this section is not without controversy - the advice on two-tiered version control, with "enterprise" version control system that satisfies the management and "developer-friendly" system that meets developers' needs seems detached from the realities of configuration management on a software project of any significant size.
The the book is organized into loosely related chapters that do not appear to form a cohesive whole with the beginning and end. The book starts with the story of Challenger shuttle disaster, but the author does not relate this story to professionalism in software development in any way. The ending is abrupt and with no conclusion - the description of the author's workstation looks out of place.
This book should be credited primarily for an attempt bring into focus the complex subject. The treatment however is shallow and the advice too often sounds subjective and unsubstantiated.