Best Practices 2004 (East)
I was in Boston during the week of Sep 20, 2004 and attended Best Practices conference. It was sort of fun, I get to see faces behind author of many books I own and articles I enjoy a great deal.
Here are excerpts from a few of noteworthy lessons:
Tom DeMarco’s five core risks for technology projects:
- Size inflation: The project grows beyond the basic set of functionality into the realm of impossibility.
- Original estimate flaw: Management sets a date that has no statistical relevance to reality.
- Personnel turnover: “This is your biggest risk if your project is anything over a year,” according to DeMarco.
- Failure to concur: A breakdown among the interested parties, often culminating in litigation.
- Productivity variation: The difference between the assumed and the actual team performance
Finally, DeMarco presented a useful self-test for checking to see whether you’re actually doing risk management:
- Is there a census of risks with at least 10 to 20 risks on it?
- Is each risk quantified as to probability and cost and schedule impact?
- Is there at least one early transition indicator associated with each risk?
- Does the census include the core risks indicated by past industry experience?
- Are risk diagrams used widely to specify both the causal risks as well as the net result (schedule and cost) risks?
- Is the scheduled delivery date significantly different from the best-case scenario?
The projects in four asset classes: infrastructure (allowing basic enterprise capability; improving flexibility and integration), transactional (focusing on reducing cost and boosting productivity), informational (based on information for managing the company) and strategic (focusing on sales growth and competitive advantage). Based on your company’s objective, the proportions in each of the four classes vary.
Abstract Prototyping
Interface designers have basically two prototype choices: figurative (conventional pictorial representations that reflect what the user actually sees) and abstract (conceptual diagrams, notations and descriptions). And since abstract prototypes isolate and simplify design decisions, Constantine, a self-professed third-degree wizard, likes starting from the abstract before developing the figurative.
The process of deriving the abstract prototype using canonical components from task case steps included:
- For each task case, identifying the contents without regard to the final layout on sticky notes.
- Repositioning components to explore layouts (sticky notes were useful for this).
- Sketching on paper or computer the size, shape, position and composition combinations.
- Refining and redrawing as needed.
PM Metrices
- Earned value: How many person days you need to do a project. Instead of focusing on how much time has elapsed, you should look at a particular deliverable, measuring what’s been accomplished and comparing the ratio of accomplishments made to the time used.
- Release Criteria: Those few critical criteria that tell you when the project is complete.
- Estimates versus Actuals for major and appropriate minor milestones: Rothman recommended starting estimates at what she called the “fuzzy front end” of the project so as not to get caught limping toward the finish line burdened with unwieldy—and unrealistic — expectations.
- Tom DeMarco’s Estimation Quality Factor process, which provides a histogram of the most significant duality in project management: the date of estimate versus estimated end date. EQF is useful in three ways, Rothman stated: First, as an early warning sign to see if events outside your project are consuming people when they should be focused on your project; second, as a check against the initial estimations on your next project; and third, as a means of determining if you have a chance of completing the current project.
- Measure the number of requirements early on in the project, as well as enumerating the number of major and minor changes per week over the course of the project, warning about the disaster potential of midstream major requirements changes.
- Tracking defect trends can help project managers keep control of the process, enumerating how long it takes to fix defects, as well as their costs.
- Fault Feedback Ratio, examining the total picture of productivity, asking the Big Questions “What do the creators create? How much is good stuff, and how much is redo?
- Determining the number of defects that remain open and making sure developers aren’t getting stuck fixing the easiest problems first can go a long way in salvaging a project that seems headed for the barrel room.
Five principles guide good OO design, according to Martin:
- The single responsibility principle (every class should do just one thing);
- Cohesion
- The open/closed principle (abstracting modules protect them from changes in implementation)
- Modules should be open for extension,but closed for modification. Add new code for new functionality, don’t modify existing working code. Need to anticipate likely modifications to be able to plan ahead in the design. Plan ahead, but don’t implement what is not already needed
- The Liskov substitution principle – All derived classes must be substitute-able for their base class Square cannot extend from Rectangle, violation will require Reflection/RTTI.
- The dependency inversion principle (details should depend on abstractions, but not vice versa). In OO, we have ways to invert the direction of dependencies, i.e. class inheritance and object polymorphism.
- Use DI to avoid deriving from concrete classes, associating to or aggregating concrete classes Encapsulate invariant: generic algorithms, Abstract interfaces don’t change.
- Concrete classes implement interfaces, Concrete classes easy to replace.
- The interface segregation principle – Many client specific interfaces are better than one general purpose interface. High level modules should not depend on low level modules. Both should
depend.
- Upon abstractions (interfaces) – Abstractions should not depend upon details. Details should depend abstractions.