The Flow Manifesto

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:

1. 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
2. The elimination of Agile and Scrum methodologies from software development. These are little more than rebrandings with additional meetings
3. The shift of emphasis from unit testing back to blackbox testing and the restoration of dedicated QA teams embedded in development teams
4. 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
5. the termination of managers who impose social programming practices, particularly pair programming
6. The replacement of open offices and noisy social settings with private offices of single occupancy. A software development office should sound like a library
7. The elimination of compulsory morning meetings requiring rush hour commutes
8. 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
9. the restored recognition of valuable individual contributors of high capacity for detail and responsibility
10. the elimination of sports and financial metaphors in software work
11. The jettisoning of bad nomenclature and misleading neologisms and a return to accurate naming conventions in communication
12. 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
13. 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.

Resources

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.

• Why Software Testing is So Important
• Test-Driven Development is Fundamentally Wrong Part I