NEW! All the articles can now be downloaded from ACM's website. The links are on each page.
The Laws of Software Process: Auerbach Publishers 2004 (ISBN 0-8493-1489-5)
Published in 2004, LoSWP covers in depth the ideas Phil has been exploring in his column in Communications of the ACM.
Starting from the premise that software is the fifth knowledge storage medium that has existed since the beginning of the
world, LoSWP, the book goes on to describe software development as primarily a learning or knowledge acquisition
activity rather than one that produces a product. It then shows that software process conforms to a set of "Laws"
that determine how effective any process can be. This leads on to observations about the reason we have "process" and
what the true role of a systems development methodology is. The book finishes with a future look at how the human and technological
elements will interact in the project of the future.
Quest Conference Keynote delivered by Dr. Susan L. Slater at the Quest Conference in April 2009
Subtle Journey of Leadership
Don't forget: Copyright (c) 2009 Corvus International Inc. Fair use with citation please!
These are synopses (in reverse chronological order) of some of the articles published in ACM's Communications of the ACM in Phillip Glen Armour's "The Business of Software" column from August 2000 to present.
Permission is granted for fair use and to quote from these articles (with attribution please).
The Goldilocks Estimate October 2012
How much time and effort should you spend on producing an estimate? After careful thought, I have determined that the answer is somewhere between zero and infinity. Read the article to find out where.
A Measure of Control June 2012
You can't control what you don't measure? We knew that. But what if you don't control what you do measure?...
...which comes first, the control chicken or the measurement egg?
The Difference Engine January 2012
Not only are smart people often not very good thinkers, there are reasons not to have too many (like more than one) of the same type on your team.
Testing: Failing to Succeed October 2011
There are two situations that scare testers: (a) when they see way too many defects and (b) when they don't see enough. Situation (a) means the system is bad which means a lot of work, cost, and irate customers. Situation (b) might mean the system is really good, but it usually means that testing isn't working. This article unearths an 80 year old formula that shows us where the sweet spot of testing is..
Estimation theory says we can take as long as we want to build a system and get it really cheaply. Or we can pay a lot and get it quickly. This extension to Larry Putnam Sr's and QSM's SLIM estimation model suggests a couple of other mathematical functions that only kick in when we severely compress a project or equally severely relax the schedule.
Don't Bring Me a Good Idea January 2011
Why many process improvement initiatives do not get the backing they deserve even though they might be a good idea. No, because they are a good idea. And what you can do about it.
Return at Risk September 2010
Why how most companies calculate return on investment (ROI) is just plain wrong, and how it should be done.
In Praise of Bad Programmers January 2010
The tale of Bad Harold and how he made a good team a better team.
Contagious Craziness, Spreading Sanity October 2009
Both sanity and insanity within organizations are catching it seems. But insanity is far more contagious.
The Cliché Defense July 2009
Walking 110% of the extra mile walk out of the box.
The Ontology of Paper January 2009
It's amazing what putting ideas down on paper does to the ideas. Especially this idea.
The Inaccurate Conception March 2008
Don't blame the forecast for the rain. Don't blame the estimate if your project fails.
Digging CACM January 2008
An archeological excursion into CACM's past.
The Conservation of Uncertainty September 2007
The only certainty is that there will be uncertainty. Why what you might gain on the LOC swings, you will lose on the "requirements" roundabouts.
Twenty Percent June 2007
Showing how Newton's Third Law applies to estimates and software projects--equal and opposite forces at work.
Mortality Play March 2007
In which an insurance company goes to Las Vegas and makes a really big bet.
Agile,.. and Offshore January 2007
A phoenix rises from the ashes, and runs a modern project using open source tools and developers in the Ukraine.
Software, Hard Data September 2006
Some interesting results on software projects from QSM. It seems you can do just about the same with three people that you can with 29 (really).
The Learning Edge June 2006
We only learn when we are incompetent but not overwhelmed. Why the Learning Edge is better than the Comfort Zone.
The Operational Executive Sponsor March 2006
Why leaders get what they want,... that is what they really want.
Counting Boulders, Measuring Mountains January 2006
Why Mt. Everest was two feet bigger than it should have been and what this means for software projects.
To Plan, Two Plans September 2005
What D-Day and software projects have in common. Why plans can be ineffective and why we should then have two of them.
Sarbanes Oxley and Software Projects June 2005
Why people should sometimes go to prison because of the way they run their projects.
Why and how otherwise sensible organizations to not manage risk in their estimates and commitments, and what they can do about it.
The Unconscious Art of Software Testing January 2005
Testing, gut feel, and how to optimally select test.
Not Defect October 2004
Why a "defect" may not be defective at all.
The three kinds of work we do in building systems and why this makes the math of projects rather extreme.
Beware of Counting LOC March 2004
So, what's so wrong about counting Lines of Code anyway?
When Executives Code January 2004
Hey, what would happen if we let the CEO code?
Closing the Learning Application Gap September 2003
The inherent limits on software engineering (or any other) education, and what we can do about it.
In The Zone May 2003
Why this might be a better paradigm for modern projects than the "roles and responsibilities" focus of the man-to-man defense.
The Reorg Cycle February 2003
Why reorganizations are inevitable consequences of the structure of companies and why they will continue to occur pretty much as the seasons of the year will continue to occur.
Ten Unmyths of Project Estimation November 2002
There are many truths about project estimation that are just not very true. Here are ten of them. They explain, in part, why we are just not very good at estimating, though there are other reasons too.
Projects are machines intended to build systems and they contain mechanisms of process, and roles, and functions and metrics. But they also contain people, and this gives projects an "organism" that we have to take account of.
The Spiritual Life of Projects January 2002
The most popular article in the Business of Software series. Talks about the forgotten (in software) dimension of people and teams.
Zeppelins and Jet Planes October 2001
A metaphor for old and new projects. One of the more popular articles.
Matching Process to Types of Teams July 2001
Why a one-size-fits-all form of software process doesn't work very well. Not only are different teams doing different things, the same team is doing different things
Software as Currency April 2001
An off-the-wall article written for the 50th Anniversary of ACM, showing that software is a modern equivalent of money
The Laws of Software Process January 2001
This was the article after which the book was named. These are the "laws" that govern the creation and application of all software processes.
The Five Orders of Ignorance October 2000
I consider myself to be an expert on ignorance; you want to know about ignorance, I'm your man. This article covers a model of the topic, with support from Isabel Lady Burton and Don Rumsfeld. Really.
The Case for a New Business Model August 2000
Published in August 2000, this was the first article in The Business of Software column and sets the theme for the articles that follow, namely Software is not a Product--it is a Knowledge Storage Medium. From this simple premise we arrive at a very different view of software development than the traditional one.