Return to what works and jettison the fads
The software industry is in as deplorable a state as American politics. It is driven by destructive and insane protocols and is not working. The
(1) vitality of cognitive focus and
(2) the destructiveness of interruptions
are both now entirely unrecognized and it is these understandings that enabled the past greatness of this crippled industry.
Software development does not deserve the honor of “engineering.” It is further from engineering than economics is from science. Engineers don’t have “personal styles” for blueprints and they have standard procedures for testing that are determined by recognized regulatory bodies.
Learn To Focus
The industry focus has shifted to testing because people are writing lousy code loaded with bugs. People write lousy code because they can't concentrate. They can't concentrate because they are constantly interrupted. They are constantly interrupted because of meetings, a noisy environment, and a peculiar outlook of software development as some sort of social activity.
The solution is not wasting time on writing tests. The solution is better working conditions.
Better Working Conditions
The return to good software development requires several strong and unhesitant steps, foremost of which is:
the aggressive and unapologetic restoration of Flow, prolonged and unbroken concentration, as the primary goal of software management. This begins with a steep reduction in the number of meetings and routine cancellation of the few that remain.
The items of this manifesto are:
- The removal of all influence of Kent Beck on software practices, specifically all aspects of Extreme Programming and most of Test-Driven Development. These are counterproductive and in some cases sadistic
- The elimination of Agile and Scrum methodologies from software development. These are little more than rebrandings with additional meetings
- The shift of emphasis from unit testing back to blackbox testing and the restoration of dedicated QA teams embedded in development teams
- The restoration of software documentation as something prerequisite to all serious work and the elimination of the idea that design is something done in tests
- the termination of managers who impose social programming practices, particularly pair programming
- The replacement of open offices and noisy social settings with private offices of single occupancy. A software development office should sound like a library
- The elimination of compulsory morning meetings requiring rush hour commutes
- the institutional cultivation of extended attention spans and the aggressive elimination of interruptions of all kinds and the termination or reassignment of engineers who cannot concentrate from having grown up with instant gratification in their lives and consumption of entertainment
- the restored recognition of valuable individual contributors of high capacity for detail and responsibility
- the elimination of sports and financial metaphors in software work
- The jettisoning of bad nomenclature and misleading neologisms and a return to accurate naming conventions in communication
- the elimination of the notion of “personal styles” in code formatting and software design and their replacement with rigorous and technically-justified patterns of work as genuine engineers use
- the exploration of new and deprecated factors enabling Flow, including but not limited to work from home and excuse from recurring and other meetings
The alternative is to let what few companies are not saddled with the nonsense currently in vogue outstrip all those burdening developers with counterproductive fads and putting them out of business, leading to extended joblessness.
Justifications for the recommendations above are detailed in the articles below. The above document represents the conclusions taken from the arguments I have presented separately. Please read them before retorting with uninformed rage. ’’Your wrong” is not a rebuttal.
- The Magnificence of Flow
- Software Development Isn't About Unit Tests
- Why Software Testing is So Important
- Test-Driven Development is Fundamentally Wrong Part I
- Test-Driven Development is Fundamentally Wrong Part II