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: Flow the aggressive and unapologetic restoration of , 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 on software practices, specifically all aspects of Extreme Programming and most of Test-Driven Development. These are counterproductive and in some cases sadistic all influence of Kent Beck The methodologies from software development. These are little more than rebrandings with additional meetings elimination of Agile and Scrum The shift of emphasis and the restoration of dedicated QA teams embedded in development teams from unit testing back to blackbox testing The as something prerequisite to all serious work and the elimination of the idea that design is something done in tests restoration of software documentation the termination of managers who impose social programming practices, particularly pair programming The replacement of open offices and noisy social settings with A software development office should sound like a library private offices of single occupancy. The elimination of requiring rush hour commutes compulsory morning meetings the and the aggressive elimination of interruptions of all kinds and the from having grown up with instant gratification in their lives and consumption of entertainment institutional cultivation of extended attention spans termination or reassignment of engineers who cannot concentrate the restored recognition of valuable individual contributors of high capacity for detail and responsibility the elimination of in software work sports and financial metaphors The jettisoning of and a return to accurate naming conventions in communication bad nomenclature and misleading neologisms the in code formatting and software design and their replacement with rigorous and technically-justified patterns of work as genuine engineers use elimination of the notion of “personal styles” the exploration of new and deprecated , including but not limited to work from home and excuse from recurring and other meetings factors enabling Flow The alternative is to let what few companies are 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. not 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. 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
