[TMMM] Ch 15 – The Other Face

<< Ch. 14 – Hatching a Catastrophe

It is not enough to just talk about documentation, the “masters” need to show the kids how to do it!

Read More »

Posted in The Mythical Man Month | Tagged , , | Leave a comment

[TMMM] Ch 14 – Hatching a Catastrophe

<< Chapter 13: The Whole and the Parts

Milestones or Millstones

The first step to keeping a schedule is to actually have a schedule.

When designing a schedule, you’ll obviously need milestones.  The milestones must be concrete, specific, measurable events.  Don’t choose vague tasks like “coding” or “designing”, because coding is always 90% finished, and debugging is always 99% done.  Pick concrete milestones that are 100% events.  Ex. “debugged version of build passed all test cases”, or “specs signed by architect and implementers”

Read More »

Posted in The Mythical Man Month | Tagged , , | 1 Comment

[TMMM] Ch 13 – The Whole and the Parts

<< Chapter 12 Sharp Tools

Designing the Bug Out

Bug-Proofing the Definition

Bugs arise from mismatched assumptions made by the authors of various components.  It is essential, therefore, to maintain conceptual integrity.

Careful function definition, careful specification, and disciplined exorcism of frills of function & flights of technique all reduce the number of system bugs that have to be found

Read More »

Posted in The Mythical Man Month | Tagged , | 2 Comments

[TMMM] Ch 12 – Sharp Tools

<< Chapter 11: Plan to Throw One Away

Programmers shouldn’t keep their tools a secret.  The first major problem to a software projects is communication, and personalized tools hamper communication.  Also, the tool lifetime is short due to changes in technology and changes in the language.

It is better to have a common development and maintenance of general-purpose programming tools.

Read More »

Posted in The Mythical Man Month | Tagged , | 2 Comments

[TMMM] Ch 11 – Plan To Throw One Away

<< Chapter 10: The Documentary Hypothesis

Pilot Plants and Scaling Up

Chemists know that a process that works in the lab cannot be implemented in a factory in only one step.  Pilot plants are used to work at an in-between scale.

For software projects, the 1st iteration will almost always suck, its big, slow and awkward to use.  Rewrites are almost always necessary; because it is very rare to get it right the first time.

Plan one to throw away, you will anyhow!

Read More »

Posted in The Mythical Man Month | Tagged , , | 3 Comments