If you happen to be reading the 20th anniversary edition of The Mythical Man-month, you can skip right to Chapter 18 for an outline of the entire book. Why this was added later is anyone's guess...
- Adding more people into a project that is overdue, makes it even later.
- Throwing people at project without consideration of training, reallocation and communication is a disaster.
- I used to apply the naive way of calculating time for a project. I was often wrong.
- Eventually I found that using 4x the time of the initial estimates works well.
- This is based on the assumption of degrees of freedom. If only developer is estimating, it is 2x original estimate. If requirements are incertain, then add additional 2x. This amounts to 4x.
- Time for administration and ramp-up is often underestimated.
- Concept of 10x contributor
- While small sharp teams maintan efficiency and conceptual integrity, they are still too small for large projects. Large teams on the other hand, introduces entire class of management problems.
- "The Surgeon Team" as the middle ground - One mind, but having different roles and responsibilities.
- Don't quite buy into the idea of the surgeon team. It is very unlike the team I know where T-shaped engineers are preferred. Mostly generalists but specialists in some area of software like devops or security.
- Important to have system architects to develop and ensure "conceptual integrity"
- Can the system stand the test of common-man understanding.
- Neither function for simplicity alone achieves conceptual integrity.
- Generally agree. Any engineer on the team should be able to see some sense in why the system is built that way, and have a sense of how each domain interacts with another.
- If it is too complicated, then it introduces additional cognitive load.
- It is also important that the team can agree on the same programming paradigm so they can apply the same mental model to the code.
- It is very tempting to overengineer a system; this is due to "Second system" effect.
- True, be aware of over engineering a system.
- Architects must communicate decisions via formal and informal documentation and tests where possible; this is part of the process to maintain conceptual integrity.
- Use different mediums to communicate semantics: Written documentations, product tests, meetings and discussions, logs, etc.
- Yes, generally true. I think teams can use different mediums and avenues to document effectively.
- Tests document product specs. Written manuals document implementation and historical decisions. Jira to document production manifest and bugs.
- Tree like structure of organisations is a natural abstraction that divides comminication and tasks into increasing specialised roles.
- The producer - modern day: project manager or delivery manager.
- The technical director - modern day: tech lead or engineering manager.
- Different hierachy and structure between producer and technical director can generate vastly different results.
- When I was technical director at PT, it was helpful that my partner give me technical authority and rarely stepped in the technical decisions. He was able to effectively use my knowledge to drive innovation, but ultimately business makes the call.
- At NF it was the reverse. I call the shots for the platform and company provided all resources to build the platform. Engineering drives the innovation.
- Harr's data. The more people they are on a project, the less effective each unit is. Effectiveness is measured by number of words per man-year.
- For a large scale project 200+ people, programming rate output only caught up to estimates after 9 months since proejct kick off.
- Complexity scale: batch processing 1x < compilers 3x < operating system 9x
- The point to learn here is that the more general a software is, the more cases it needs to cover and therefore the complexity increases significantly.
- Software projects should come with space and time constraints where possible.
- Representation is the essense of programming.
- Generally true. Instead of looking at optimising routines and refactoring small pieces of code, step back and look at the larger data structure. If other structures can be used, then it follows that other processing techniques can be applied to achieve a more optimised design.
- Think back on the online algorithms class. Percolation problem interpreted as a binary tree.
- 3 way tug betweem Forecast, Estimates and Prices.
- Formal documents are important to record decisions and to communicate decisions to others.
- Objectives, specifications, schedule, budget, organisation chart
- Change is constant, learn to quantize changes
- Structure organisation to change
- Assign people to jobs that broaden them
- Fundamentally a social problem. Senior people should ready to execute and code. They should not feel demeaned.
- As usage becomes for frequent, more bugs are uncovered.
- Fixing a bug typically has a 20% to 50% change to introduce new bug.
- Most systems eventually reach a point where fixing ceases to gain any new ground.
- Important to have good development and software tools. The toolings to consider
- Development env. Should be easy to set up, consistent with others.
- Testing env. Should be robust and accurate
- Source versioning
- Documentation tooling
- Language features
- Interactive debugging
- Good conceptual integrity helps to eliminate bugs early on.
- Divide large system routines into a series of smaller steps or modules.
- Embrace unit testing, and use tested components.
- Use scaffolding and factories for debugging and testing
- Quantize changes.
- Milestones should be sharp and unambiguous
- Trying to keep estimating before starting an activity is useless
- Overestimations usually fall after the start of activity
- Underestimations do not show up until shortly before completion
- Do not be late, even if not on critical path
- About manager behavior
- Do not act on problems that managers can solve
- Do not act on problems when purely reviewing
- Meetings should have 2 styles
- Status review meetings
- Problem action meetings
- Planning and control as a dedicated role is effective
- Programe documentation should be comprehensive
- Purpose, env, I/O, options, performance, etc...
- Test cases will make the programe believeable
- There should be charts and diagrams to show others how a program works before they can modify it.
- Programs should be self documenting.
Chapter 16 onwards are new chapters that are part of the 1995 refresh of the book. Fred Bookes added new chapters to address software engineering in dot com era. The chapters hereon are a lot more relavant.
- 2 key types of complexity in software engineering projects
- Essense / Essential - difficulties inherent in the nature of software
- Accidental - avoidable errors in the process of developing software
- Characterisic of Essential Complexity
- Data, algorithms, procedures -> all part of business complexity
- They are highly precise and richly detailed.
- A software devoid of essential complexity is poorly conformed.
- Extremely complex, often scaling non-linear interactions
- "Abstracting complexity > Abstracting essense"
- High conformity
- Match insitution an systems and to new opportunities.
- High Changability
- Software is pure-though stuff.
- Invisibility
- Software is inherently unvisualizable
- Data, relationship, dependencies, temporal information, time-space, patterns
- There is not much that can be done about essential complexity
- High-level languages
- No matter how high level, languages have limited breakthrough in terms of overall complexity. Current available tooling as alrady removed most accidental errors.
- Object-oriented programming
- Brooks believes that the order of magnitude of productivity can only be achieved if abstract and hierachical types are modelled extensively, i.e. fully utilise the features of OOP completely.
- Expert systems
- Brookes believes that expert systems can dramatically bring down the accidental complexity
- Reason is because changable parts of the application are uniform in fashion (He probably means that there are limited primitives to prevent too many differences in implementation and expression)
- Program verification
- Sidesteps the complexity problem, but it does help in QA
- Buy vs. Build
- Buy where possible if the software can be highly applicable to business.
- Train staff on generalized software like spreadsheet (1995 context)
- Requirements collection
- Brooks believes that new approaches to collecting requirements will be the key driver to reduce complexity
- Modern day agile
- "Conceptual structures too complicated to be accurately specified, is too complex to be built faultlessly"
- Grow not Build
- Software construction is a creative process
- There is great value in software design. Spend resources to groom them
- Follow on the original 'No Silver Bullet', chapter 16.
- On accidental complexity, he emphasizes that there is no point in reducing accidental complexity to <10% as it no longer contributes a magnitude of productivity improvement.
- "System complexity is a result of organisational malfunction. Conforming to this reality with equally complex solutions results in conserving this mess, instead of fixing root problems."
- Complexity is often not a result of conformity, but rather due to implementation itself such as data structures, algorithms, interactions, etc.
- Productivity follows quality
- Software development discplines were developed as a response to quality concerns (preventing major accidents), and not productivity.
- It is found that productivity is 3x-5x in high quality projects.
- Low abstraction yields very low returns.
- Small encapsulation yields small benefits.
- Design large-grained classes that address concepts that clients are using
"Unless we teach people how to design, the languages matter very little." - David Parnas
- Reuse should be encouraged
- Very difficulty to implement as it requires great design and even greater documentation.
- Reusable components typically take 3x more time compared to one-use components
- The nature of code reuse also necessitates a diverse vocabulary to describe the classes, especially true for OOP where natural language is used.
Well it's an outline of the entire book... the Brooks even trolled us in the chapter's opening...
- Conceptual intergrity is central to product quality
- Appoint a dedicated system architect
- Define user persona
- WIMP example
- Conceptual integrity of Window, Icon, Menu, Pointer
- Commands made of verbs and direct objects
- Balancing user power and ease of use.
- Ease of use -> achieving uniformity
- User power -> efficiency
- Nightly builds
- Modern day CI/CD
- Adding more people to a late project increases cost but does not always complete later.
- New people have immediate negative effect, takes weeks to compensate.
"Manager's function is not to make people to work, it is to make it possible for people to work"
- Preserving the creativity of smallness
- Delegate power down to individual teams
- The team settles squabbles, the bosses don't
- Expanding on shipped products, not giving end users more power.
- Attacks the essense of fashioning conceptual constructs.