System Design, Project Management, and Architectural Insights

CS 428 THE MYTHICAL MAN-MONTH Chapters 4, 5, 7, 11, 14,16-19 FALL 2024 BRUCE F. WEBSTER

Ch 4: Aristocracy, democracy, and system design 2 Brooks: conceptual integrity is the most important consideration in system design (I agree) Simplicity, straightforwardness, unity of design are necessary The design must proceed from one mind or a very small number of agreeing resonant minds The conceptual integrity of a system determines its ease of use A consistent architecture enhances the creative style of implementers A well-thought-out architecture increases the robustness and adaptability of the resulting software system

3 Ch 5: The Second-System Effect Interactive discipline for the architect The architecture is valuable input into estimating the implementation and testing If the schedule is unacceptably long, the architect can look for ways to simplify Big challenge: features that may seem simple to the customer may actually be very difficult to design and implement The second-system effect Brooks notes later that true iterative development can diminish this problem, but The first shipping version usually has many deferred features; there is a strong temptation to throw in everything but the kitchen sink into version 1.1 or 2.0 Real-world issue: incurring technical debt and not handling it

Ch 7: Why Did the Tower of Babel Fail? 4 What they did have: A clear mission Manpower Materials Time Technology What they lacked: Communication And, as a consequence, organization Your observations/experience?

Ch 7: continued 5 Project workbook: replaced today by online organization (e.g., github, your project wiki, etc.) Communication challenge: with n workers on a project, there are (n2-n)/2 possible interfaces and 2n possible sets of workers Solution: Division of labor / specialization of function Key: project manager and chief architect need to be different people Their priorities conflict Chief architect will tend to be overly optimistic

Ch 11: Plan to throw one away 6 As with second system effect , Brooks feels his comments here are superseded by use of iterative/incremental software development Still, far too often, pilot or prototype systems are forced to evolve into production systems Only after your first cut do you often see how you should have done it in the first place What has been your observation/experience?

Ch 11: Continued 7 Plan the organization for change Still a very real issue: lack of technical advancement track in most organizations Instead, developers are pushed into management if they want to be promoted Two steps forward and one step back Most maintenance work involved adding new features Introduces software entropy (or, if you prefer, software rot) Production systems that are modified become less stable/reliable over time Less effort is spent on fixing original design flaws; more is spent on fixing flaws introduced by earlier fixes Your observations/experience?

Chapter 14: Hatching a Catastrophe How does a project get to be a year late? One day at a time. Milestones must be concrete, specific, measurable events 8 The myth of the Oh, we re about XX% done statement 90/90 rule: 90% of the project takes the first 90% of the schedule; the remaining 10% of the project takes the other 90% of the schedule. The three weeks before deadline rule: Underestimates [of project schedule] do not change significantly during the activity until about three weeks before the scheduled completion. Need for a critical-path schedule (e.g., PERT) to show the critical path Observations?

CH 14: Continued 9 Not being willing to pass bad news uphill Webster: The Thermocline of Truth (2008) [Webster #2] Not knowing the news is bad Webster: Lies, Damned Lines, and Metrics (parts I through III) (2008) [Webster #3] Project progress metrics need to be objective, repeatable, and informative Weinberg s Law of Metrics: That which gets measured gets fudged. The Metric Law of Least Resistance: The more human effort required to calculate a metric, the less often (and less accurately) it will be calculated, until it is abandoned or ignored altogether. Thoughts and observations?

Ch 16: No Silver bullet: Essence and Accident in Software Engineering (1986) 10 Probably one of the single most important essays ever written about information technology Core argument: Building software will always be hard. There is inherently no silver bullet [to slay the monsters of software development]. Four inescapable essential difficulties in software development Complexity: increases non-linearly with program size, both technically and managerially Conformity: code must work with its ever-more-complex environment Changeability: constant pressure to improve or fix existing systems Invisibility: software is extremely hard to inspect and examine (vs., say, a building)

Ch 16: No Silver bullet (cont.) 11 Things that do help Buy vs. build Buy and adapt (or adapt to) an existing solution that someone else had built and maintains Requirements refinement and rapid prototyping it is really impossible for clients, even those working with software engineers, to specify completely, precisely, and correctly the exact requirements of a modern software product before having built and tried some versions of the product they are specifying. Incremental development A large, complex system that works is inevitably found to have evolved from a small, simply system that works. John Gall, Infomatics Great designers The very best designers produce structures that are faster, smaller, simpler, cleaners, and produced with less effort. . . . Those software systems that have excited passionate fans are the products of one or a few designing minds, great designers. Analysis and observations?

Ch 17: No Silver Bullet Refired 12 I can t help noticing that the nostrums published so vigorously in 1986 and 1987 have not had the dramatic effects claimed. Brad Cox in 1990: The reusable, interchangeable component approach [is] an attack on the conceptual essence of the problem. This lead to the reuse push of the 1990s, which failed utterly. David Harel in 1992 offers The Vanilla Framework . Ever heard of it? Object-oriented development: also another brass slug (hence my book Pitfalls of Object-Oriented Development[1995]) Brooks says his analysis stands; 30 years later, I agree with him. Analysis and observations?

Ch 18: Propositions of The Mythical Man- Month: True or False? 13 Hint: this chapter is a great cheat-sheet for the open-book midterm

Ch 19: The Mythical Man-Month after 20 years 14 Why has The Mythical Man-Month persisted? Again, me before Congress in 1998: "Fred Brooks explored many of the root causes [of IT project failure] over twenty [now over forty] years ago in The Mythical Man-Month, a classic book that could be regarded as the Bible of information technology because it is universally known, often quoted, occasionally read, and rarely heeded."

Ch 19: The Mythical Man-Month after 20 years (Cont.) 15 Brooks sees his central argument not about scheduling or staffing, but rather about conceptual integrity and the need for a chief architect Second-system effect: define the set of users: Who they are What they need What they think they need What they want It is far better to be explicit and wrong than to be vague. [Why?] Triumph of the WIMP interface, which Brooks sees as eventually being replaced by voice (I disagree)

Ch 19: The Mythical Man-Month after 20 years (Cont.) 16 Build one to throw away as we discussed, Brooks abandoned this in favor of iterative development but most waterfall is iterative these days as well Brooks acknowledges his fault in rejecting information hiding and now sees it as essential The mythical man-month: Boehm shows that hardly any projects succeed in less than of the calculated optimal schedule, regardless of the number of people applied. Brooks Law: yes, there are cases where adding people can help but I stand by the bald statement as the best zeroeth-order approximation of the truth, a rule of thumb to warn managers against blindly making the instinctive fix to a late project.

Ch 19: The Mythical Man-Month after 20 years (Cont.) 17 People are everything (well, almost everything) Cites Peopleware by DeMarco & Lister (your next book to read) Boehm s studies: the quality of the team is by far the largest factor in its success, indeed four times more potent than the next largest factor. The power of giving up power Effective software management means building teams and letting them succeed The biggest surprises? Millions [really billions] of computers [and now mobile devices] Massive amounts of shrinkwrap software (and now apps) Note: he talks about 4G languages like Hypercard, which again have failed to pan out