Jan writes: One of my current reads is "Programmers and Managers", 1977. I was curious about the conflict between developers and management, particularly since it seems to be with the discipline since at least the 60s. blog
book ![]()
Thread of discussion matrix ![]()
Ward replied with links to many wiki pages and some observations to connect those thoughts to Jan's inquiry:
In this presentation Alexander goes on at length on the observable structure of beauty but closes with a call to action after observing, "that those of us who wield the power to transform the world have accepted the role of technicians, hired guns, serving other interests."
Beauty appears as a central motivation again here from Dijkstra who was mentioned above in "Programmers and Managers". Dijkstra argued that only the most skilled logician could appreciate beauty in a program as a proof. His notion of "weakest precondition" transferred easily to TDD.
Here Richard Cook explains the tension between those who know (engineers) and those who want (management). Systems seem to run at the very edge of failure much of the time. The combination of high workload, limited resources, pressure for additional features and capability, and inherent software, hardware, and network fragility is a noxious kettle of stuff always about to boil over in the form of outages, degraded response, or functional breakdowns.
A the dawn of desktop computing the "customer" that agile speaks of was often the "user" selected by management to get the new, yet to be programmed, workstation. An often lost aspect of extreme programming was the expectation that the customer/user could demonstrate on a weekly base the accomplishments of recent collaborations. In this way the decision maker was demonstrating requisite variety to make good decisions as to the future they desired.
I thought it interesting when the proponents of various "live" programming tools gathered recently that another shift in culture, not just technique, was on the horizion. Deadlines were identified as an obstacle to live-culture, a programmer-management conflict? The suggested solution was to redefine the goal such that development could return to live activity. In my own Episodes pattern language I called this Work Split, and this served the same purpose of aligning expectations of creative work.
Several authors have returned to my 1994 pattern language dubbed Episodes. This has been recognized as a founding work in the history of Agile. So an inquiry into roots of the now accepted and consequently diluted practices might want to know more about how Episodes came to be.
Conversation continues with much more historical and cultural context when Mike Hales replied. matrix message ![]()
Brian Marick replied with thoughts that align with my own sense of history. Thread of discussion mastodon ![]()
.
- [x] find the related links from other parts of the conversation. - [x] create a page for Programmers and Managers - [ ] continue pulling in insights from Mike Hales replies in Matrix chat and thereafter - [ ] pull insights from Brian Marick's replies in mastodon