Coaching is a key tool to help individuals and teams reach peak performance. One of the key attributes of a good coach is empathy. I was recently drawn into a discussion about the role of empathy in coaching. Critical to the understanding the role that empathy plays in coaching is understanding the definition of empathy. One of the most difficult parts of the discussion was agreeing on a common definition . (more…)
November 25, 2015
Leave a Comment
November 22, 2015
Leave a Comment
Subscribe on iTunes
The Software Process and Measurement Cast 369 features our essay on stand-up meetings. Stand-up meetings are a combination of tactical planning on steroids and the perfect start to a great day. Stand-up meetings are one the easiest Agile practices to adopt and often one the easiest to mess up.
Also, this week features we have Kim Pries and his Software Sensei column. Kim discusses what it takes to move toward mastery. Mastery implies more than just being good at any particular task. The Software Sensei provides a path forward.
Gene Hughson brings the first of his discussions on the topic of #NoEstimates from his Form Follows Function blog! Specifically Gene provided a more detail and background on his essay #NoEstimates – Questions, Answers, and Credibility.
November 21, 2015
Leave a Comment
Airports and driving have conspired to keep me from finishing this week’s essay from The Mythical Man-Month, therefore I thought I would seek your advice. The Re-Read of The Mythical Man-Month by Fred P. Brooks is nearly complete. We have one very long retrospective essay and an epilogue left in the book and a summary essay from me. I anticipate one or two more weeks of posts. The burning question is: what is next? We have re-read Stephen Covey’s Seven Habits, The Goal by Goldratt and now The Mythical Man-Month. I have two questions for you. 1) Do you want me to continue with this feature? And, 2) which book should be next? It is time for a poll. If you would like to suggest a book that is not on the list, feel free to “write-in” a candidate in the comments for this essay. I have included the top entries from the poll I did a few years ago and a few suggestions readers and listeners have made along the way (or books I have rediscovered as I poked around my library). (more…)
November 19, 2015
Leave a Comment
In recent exchange after the 16th installment of the re-read Saturday of the Mythical Man-Month, Anteneh Berhane called me to ask one of the hardest questions I had ever been asked: why doesn’t the definition of done include value? At its core, the question was asks how can we consider work “done”, if there is no business value delivered, even if the definition of done is satisfied including demonstrably meeting acceptance criteria. Is software are really done if the business need has changed so what was delivered is technically correct, but misses the mark based on the business environment today? This is a scenario I was all too familiar with during the 1980s and 1990s at the height of large waterfall projects but see less in today’s Agile development environment. Anteneh Berhane’s question reminds us that the problem is still possible. We discussed five potential problems that disrupt the linkage between done and value. Today we will discuss the second three. (more…)
November 17, 2015
In recent exchange after the 16th installment of the re-read Saturday of the Mythical Man-Month, Anteneh Berhane called me to ask one of the hardest questions I had ever been asked: why doesn’t the definition of done include value? At its core, the question was asks how can we consider work “done”, if there is no business value delivered, even if the definition of done is satisfied including demonstrably meeting acceptance criteria. Is software are really done if the business need has changed so what was delivered is technically correct, but misses the mark based on the business environment today? This is a scenario I was all to familiar with during the 1980s and 1990s at the height of large waterfall projects but see less in today’s Agile development environment. Anteneh Berhane’s question reminds us that the problem is still possible. We discussed five potential problems that disrupt the linkage between done and value. Today we will discuss the first two and Thursday the next set. (more…)
November 15, 2015
Leave a Comment
November 14, 2015
In the essay No Silver Bullet, Refired, Brooks reexamines his essay No Silver Bullet (aka NSB or last week’s re-read) nine years after its original publication date. Both essays were additions to original 1974 The Mythical Man-Month as Brooks sought to project the course of the software development industry. As sadam510 pointed out on the blog last week, we have passed out of the traditional Re-Read territory and are now cutting through ‘fresh’ snow. NSB was originally published in 1986, and NSB, Refired was published nine years afterwards both to address the criticisms and to examine how the world had progressed.
Brooks begins the essay by addressing some of the misunderstandings that were generated by his particular brand of prose (several readers have commented that these later essays are a reflection of Brook’s involvement in academia, that is, the straight-on writing style of the earlier essays had become more difficult to understand). The first of the misunderstandings he tacked was the distinction between essence and accident. Brooks reminds the readers that the word ‘accident’ was used to mean incidental. The essence of a software application is the logic needed to solve the business problem, while the coding language or development environment are incidental to solving the business problem. The second point of misunderstanding focuses on the how much of the effort or complexity of creating an application was caused by incidental factors versus the essence. Brooks argued in NSB that the essence was the most significant factor, and in NSB Refired he reiterated that stance. While both essence and accidental are meaningful, in order to generate an order of magnitude change, the complexity of the essence must be reduced.
The second thread in the essay featured a rebuttal of David Harel‘s analysis/criticism. Brooks felt that Harel’s criticism was one of the most well-formed, therefore he spent significant effort to rebut it. Harel criticism begins by arguing that Brooks’s conclusions were pessimistic and gloomy. On the pessimistic side Brooks defended his perspective by suggesting he is at worst he was realistic based on his developer’s background. Developers tend to be optimistic about the ability to solve ANY problem (note Dr. Ricardo Valerdi in his interview on SPaMCAST 84 provided evidence to support this position). Brooks stated that taking an overly rosy view as suggested by Harel of the potential for change was a pipe dream. In Brooks’s opinion, pipe dreams do not create the pressure needed for progress. On the topic of gloomy, Harel suggested that Brooks perspective grew out of three sources:
- The sharp delineation between essence and accident, which he believed was artificial.
- The 10-year time horizon used by Brooks was overly short.
- Analyzing each silver bullet separately ignored the relationships and potential synergy between the potential silver bullets.
As a thought experiment in the critique, Harel applied the essence and accident analysis Brooks used in the NSB to the development world of 1952. Harel suggests the structure used by Brooks would only fit in a very specific timeframe, and therefore, would not necessary hold in the future. Brooks rejects the thought experiment by pointing that as soon as large-scale systems began to be addressed (approximately 1954), the analysis approach works.
Harel completed his criticism by proffering his own silver bullet based on a system of modeling the concepts of the application (in Brooks’s language, the essence). There was an undercurrent in the essay that many of those criticizing NSB were doing so to suggest a silver bullet. In this case, while Brooks agreed with the idea of leveraging models to identify and develop the conceptual basis of the application, he noted that most developers develop their own highly individualized conceptual models of what they are working on and that they are not typically generalizable.
Another class of criticisms suggests that Brooks’s focus on productivity in NSB was misplaced. Rather, as noted by Caper Jones (former boss, friend, and mentor), the focus should be on quality and then productivity will follow. Brooks suggests whether focusing on quality or productivity the conclusions of the NSB don’t change. (I think I will ask Capers his opinion…)
After reviewing the criticisms, Brooks circles back to review what has happened to productivity in the years between NSB and NSB, Refired. Capers Jones’ data suggests that for comparable programming languages it had productivity had increased three-fold; while Ed Yourdon had evidence of up to five-fold increases. Large changes, but as Tom DeMarco indicated, not an order of magnitude increase. In order to understand where the productivity improvement had come from Brooks re-examined some the major categories from the NSB.
Build versus buy had become a powerful tool (and still is in 2015). The ability to customize software packages easily has continued to increase the power of commercial off-the-shelf software. Packages like SAP and PeopleSoft are perfect examples of the increased productivity configurable/customizable packages deliver.
Brooks suggests that object oriented development (OO) represents at least a brass bullet. OO has delivered value and continues to show promise. Even today OO continues to grow in use and value (even though OO has not fundamentally changed productivity by an order of magnitude and is therefore, no silver bullet). In hindsight from 2015, OO has continued to penetrate and deliver value, but it has not changed the world . . . yet.
Reuse Brooks found was being done in pockets but that it had not spread to the degree he had suggested in NSB would be needed to actually be a silver bullet. The advent of natural language programming languages may have inadvertently added complexity to adopting reuse programs. Natural languages make finding patterns to reuse harder. While not an insurmountable problem, they add complexity, effort and the killer – cost, which has slowed the adoption of reuse. My personal observation from 2015 suggests that reuse is still a marginal practice due to the overhead required to identify and package generalized functions.
In the end, despite all of the criticisms and critiques, Brooks’s position is unchanged. He states that “complexity is the business we are in and complexity is what limits us.” Until complexity is conquered there will be no silver bullets, only incremental improvements. Not that incremental improvement are anything to sneeze at!
Programming Notes: My version of the Mythical Man-Month includes one large essay, The Mythical Man-Month after 20 Years and an epilogue. I suspected we will complete the Re-Read in two weeks. Suggestions for the next book in the series?
Previous installments of the Re-read of The Mythical Man-Month