Niwot Ridge Resources

A Source of Information for Mission Critical Software Systems, Management Processes, and Strategies

The following essays are on topics of interest to colleagues and friends. They range from technical discussions of current issues in software to science, theology, and other more useful topics. Most are works in progress, with place holders for titles.

"Managing Projects Involving External Threats," Ilya Tirdatov, American Society for the Advancement of Project Management. I came across this paper through a suggestion on the Agile Project Management forum to visit the ASAPM site. It was presented as a example of the level of work provided by the members of this project management association.

Agile Project Management and the PMBOK. The use of normative methods is common in the PMBOK. Applying these methods to software projects has been problematic in the past, since they fail to deal with the attributes of modern software projects: emerging requirements, changing technology and business environments, and the lack of stability in the business and technology domains.

What is System Architecture? There is much discussion about software architecture. Some say it is a critical step in the design of the system. Some say it "emerges" as the code is being developed.

What is IT Strategy? In many cases architecture is confused with development tactics. The same goes for strategy, the confusion that is.

Are Kepler's and Newton's Laws, laws of nature?  A discussion on the laws of physics brought out the issue that few people today have a solid grounding in the history and philosophy of science. This essay provides the background for calling a behavior of nature a physical law. (still being worked on)

Baloney Claims is a summary of a method for determining whether a claim is "baloney" or not. This essay is derived from a Scientific American series of articles directed at the scientific community

Agile Alliance, What Does the Agile Manifesto Mean? The current "buzz" in the software process world is lightweight and agile. The Agile Alliance has presented a manifesto declaring the principles of agility. This essay examines these principles in light of project management and engineering practices.

"Achieving Extensibility Through Product–Line and Domain–Specific Languages: A case Study," This paper describes an example of refactoring a complex system. It makes use of GenVoca and a domain–specific language JavaSM, to create an abstract layered architecture for an artillery fire control simulator.

Mind Manager - I usually don't do product reviews for several reasons, but mainly because I have a hard time saying the right nice things to keep the vendors of products sending me free stuff. But this is a product that I've used and would recommend to others.

iDecide – this is a Monte Carlo simulator I'm using to model IT Strategy decisions. I'll have the latest version in hand next week (mid-August 2002) and will write up a review then.

Agile Estimating and Planning ( 200k) Mike Cohn, Prentice Hall. This book describes the processes of managing agile software development projects. But it also describes agile methods of managing projects in an agile manner. Mike's approach closely matches the processes found in any mature project management method, probabilistic duration estimates, incremental and iterative deliverables, and constant focus measuring progress through the delivery of value, not just the passage of time.

Total Project Control, ( 232K) Steve Devaux, John Wiley & Sons. This book presents a project management method based on an index that claims to provide a tool for the decision maker. This index - DIPP - can be used to assess the impact of a scope change in the project. I cannot decide if I simply don't get the concept or the concept is invalid. I've gotten partly through the book, then lost interest. At $89.00 this is an expensive choice. In the mean time I'm starting a preliminary review, which recommends the reader seriously consider the price / payoff ratio of the book. This ratio did not meet my requirements for "value." A full review is in the works and I will finish it over time. The primary problem is the index Devaux has created is it  is unstable near the end of the project - it gets a divide by zero error. It is also non-linear during the project lifecycle. The result is a poorly formed performance index.

Secondly Devaux insists on ignoring the sunk costs to date for the project. This is a critical factor in any assessment of the project's ability to complete on time and on budget. The result is the inability to forecast future costs based on past performance - a core activity for any project management process. The Estimate To Complete (ETC) value used in the denominator of his DIPP index "should" (but is not) be based on past performance for future estimates. Here's a "note" (48K) on Devaux's approach and a solution to the problem of not considering sunk costs.

The much longer review linked from above tries to sort out the problems with the book. This review is likely not to please Devaux or any of his followers. I must admit it is not a very good book review since I simply can't get over how poorly the book presents the material, how loosely it is edited and how badly Devaux speaks about the those involved in PM through his somewhat lame examples. In the end Devaux seems to think project managers haven't a brain in their head - from his examples of how bad projects are managed. Following his examples, all ills will be cured. But I'm afraid the method simply doesn't hold up under scruninty.

Blind Men and the Elephant, David Schmaltz, Berrett-Koehler, 2002. Schmaltz uses John Godfrey Saxe’s “The Blind Men and the Elephant” poem as a metaphor for managing projects. This book is neither about mastering project work or transforming fuzzy responsibilities into meaningful results. Overall I would recommend this book, but suggest that the reader recognize that Schmaltz is basically anti-leadership, anti-team, rages against formal organizations, and spouts lots of personal philosophy with little acknowledgement of the current theory and practices of team based, leadership methods found in modern business. In the end there is actually advice on managing projects and how to improve the project management process – despite the failure to fully achieve the promise of the subtitle. But you have to work your way through to page 119 before this comes out.

The Microwave Way of Project Management, Bas be Baar, iUniverse Press, 2002. This book is unique in several ways. First it can be read on–line before buying, second it is the second (I’ve encountered) that claims to address the issues of PM from the point of view of agility or at least from a non–traditional point of view. I would recommend this book as a web-read before deciding to purchase it in hard copy.

Radical Project Management, Rob Thomsett, Prentice Hall, 2002. Let me start by saying this book appears to be a collection of essays by Thomsett, as well as a book length treatment of "The Busy Person's Project Management Book." I say these are essays since much of the verbiage is dated in the mid-1990's when Thomsett uses terms like "modern" and "current" for references in the late 1980's and early 1990's. This does not take away from the value of the book, but careful copy editing should have recognized that a book with a 2002 copyright needs modern references as well.

Extreme Project Management, Shaun Ajani, Writers Club Press, 2002. Extreme Project Management (EPM) is a quirky little book with much to offer and some glaring gaps. The book should be read of only to get a single idea - PM processes need to be reexamined in light of emergent development methods. The high-ceremony processes of the past are becoming obsolete.

Software Craftsmanship: The New Imperative, Pete McBreen, Addison Wesley, 2001.

This book describes a craftsmanship paradigm for the development of software. It challenges many of the traditional notions of the software engineering paradigm. Many of the principles of craftsman based development are described in other works, or provided in other methodologies. But they are restated here through the eyes of the craftsman.

This view is both new and old. Other disciplines have undergone the craftsman revival in recent times, architecture, electric appliances, other hard goods as well as the service industries, soft goods manufacturing, and even the public sector. A return to hand crafted goods and services is long over due in many of these areas. McBreen's book provides an early view of the motivations for crafting software systems.

But there are gaps...

The book contains gaps in the understanding of how software engineering is applied in many industries. His examples of large scale projects are dated, the reuse example fails to examine in detail the cause of the failure of the Ariane 5 and therefore misinterprets the results based on a press release rather than the technical reports.

There are several places in the book where McBreen makes blanket statements that have no backup reference materials, are plain wrong, or are simply unbelievable.

The book is worth reading however, if only for a fresh perspective on the issues of software development. I do have specific issues with the details underlying the concepts as well as the lack of reference material used to support the thesis that software engineering is appropriate only for large scale projects.

Much of McBreen's work appears to be opinion rather the research based. This is a personal issue I realize, but still a legitimate concern for an author claiming to present a new paradigm. His bashing of software engineering while claiming craftsmanship based development compliments it, is curious. The subject of process improvement is so complex I find it difficult, like much of the XP thesis, to believe that a simple solution exists beyond its application to a specific problem domain (for XP, 5 guys in the same room with their customer doing an interactive business system).

The subject matter is moved forward though, so in the end the book serves its purpose - to open the discussion that one size does NOT fit all.

Caveats for this review...

One caveat for this review is needed though. The language of the review is focused on criticism of what I found to be weak in the book not the praise of the strong parts of the book. Others have and will continue to do that, ranging from the publisher to other reviewers. This may be seen as a negative approach and not supporting the cause, but it is derived from a hard sciences upbringing. Anyone (well nearly anyone) can write a review that sells the ideas of the author. Positioning a book or a journal submission in the context of a larger domain is the goal of the reviewer.

The one question asked of a reader of a review should be – what did the reviewer learn about the piece that still allowed him (or her) to make a buy recommendation, while exposing the gaps in the work. Nothing is more disappointing than to buy a book ($29.00 for a smallish paper back) then discover that there are gaps. Knowing the gaps up front somehow softens the blow.

(The money is not the issue, a run of the mill physics book now costs in the range of $100.00).

Here's an example of a typical critical but supportive review of a science book, http://physicstoday.org/pt/vol-54/iss-9/p53a.html.

Another caveat is that my view of the problems of software development and their methodologies are tainted by hard science (particle accelerator controls), large real time systems, COTS integration, process controls, and mission critical fault tolerant applications. These systems are usually built inside an engineering environment, by engineers, for engineers. The engineering mentality pervades the business and technical aspects of software development.

More details...

A detailed review can be found by following the link attached to the book title.

Antipatterns in Project Management. Coming in the December 1, 2001 edition of PM World Today.

The cause of many project failures can be traced to the passivity of management and participants in the face of the forces attempting to undermine a project’s success. This characterization may seem too general, but this book lays the groundwork for understanding the repeated bad behaviors of projects and addressing their solutions.

The concept of repeated bad behavior – described as an antipattern – has been developed by the same authors in two previous books. Antipatterns: Refactoring Software. Architectures, and Projects in Crisis, Brown, Malveau, McCormick, and Mowbray and Antipatterns and Patterns in Software Configuration Management, Brown, McCormick, and Thomas are the predecessors of the current book. This is a useful background for the current book and sometimes redundant, since many of the antipatterns developed in the previous books are repeated in the current publication.

Home | Search |Site Map | Copyright