I’m with J. Michael Palermo IV in saying that functionality and quality are related, but I would say that quality is a subset of functionality. Features (functionality) really exist only if they are used, and they’re used only when they don’t suck.
Great topic - I wrote an article about this a while back (http://www.basilv.com/psd/blog/2006/understanding-project-schedules), and have a java applet that provides a visualization of the 4 variables (http://www.basilv.com/psd/software-files/launchManagementDiamond.html).
I agree that it is possible to ‘make your stool more malleable’, to use your analogy - i.e. to for example improve your quality without increasing the time required. For many projects and especially for the project managers, however, I feel they are trying to irrationally shorten all the legs of the stool/pyramid, so for those I’d prefer to send the message that the stool is made of iron. Only once you have come to understand and accept that can you move beyond the iron to more malleable substances.
You’re wrong. Quality is free; often quality is cheaper than free because it saves wasted time and rework. Think win/win.
To me, the center of software engineering is developing designs and practices that improve quality and lower cost at the same time. Unfortunately the software industry is focused on the 1950’s “quality = testing” model… Only the most advanced shops have caught up with the 1980’s ISO movement thinking.
To take an example, the other day I was finishing a web application that somebody else started. There were two controlled vocabulary terms that appeared in dropdown lists, and a rather nice editor that administrators could use to edit the list. Or rather, two copies of a rather nice list editor that were each hard coded to edit a particular variable.
I had to add a third, and maybe a fourth controlled vocabulary term. I could have “cut and pasted” one of the list editors, doing a “search and replace” for three parameters that the list depended on, and specialized it for the new controlled vocabulary terms.
Instead, I turned it into a class which took those three parameters as arguments. It took a while to replace the first dropdown, a little less time to replace the second dropdown… And just five minutes to add the third. The next day I heard from the client and understood the client needed something different, and it took less than ten minutes to make it right.
And now I’ve got a nice dropdown editor class I can drop into my next project – that will save me both development and testing time, because I know that particular module is low in defects.
Bad quality costs a lot in development time. The other day I spent an hour and a half doing a job which should have take five minutes. It turned out that the database drivers were wonky, some of my subroutines were wonky, and some of the subroutines written by the last programmer were wonky. Perhaps I “should” have used an existing subroutine, but that subroutine had an error-prone interface that I didn’t agree with. That left me having to duplicate some logic that I didn’t want to duplicate. The database drivers didn’t report errors correctly, so it took me forever to figure out what was wrong with my SQL. Here, bad quality == wasted developer time. The client may never see these hidden defects, but they make me miserable.
Of course, the scope for reuse depends on what you do. The most exciting development in the Software Engineering is Software Product Lines – probably the first real “silver bullet” that lowers cost and time-to-market while increasing functionality and quality.
The idea of SPL is that a programming shop can develop assets and practices to create a “software factory” that can rapidly turn out products that are a variation on a theme. You get the flexibility of custom software, with the cost and profitability benefits of mass market software.
Win/Win thinking benefits everyone. It saves money for clients, makes your business more profitable, and sets your programmers free to do creative work rather than continuous rework.
I maintain that quality is a feature, not a separate dimension. “Quality”, in this case, refers to Testing, Training, and Documentation - all of which are often “features” that get cut from the list to make the Schedule.
http://www.cazh1.com/blogger/thoughts/2006/10/iron-triangle-quality-is-feature-that.shtml
My boss had a triangle analogy as well, but his was:
- Stuff works
- Customer is happy
- On time/budget
His thing was that it was relatively easy to get 2 out of 3, but difficult to get all 3.
product, cost and time is adequate to describe it. don’t need 4.
product = features, quality, service, hardware, software etc.
cost = money, effort, resource (human, hardware, software) etc
time = dates, schedule, milestones etc
quality is just a characteristic of the product.
I think a good way to look at it is:
c = cost
s = speed
q = quality
c = s + q
Graphed in 3D this function is a plane.
The whole triangle/stool thing is a bit weak. The triangle is trying to say “there are three variables, time resources and functionality, and a relationship linking them”. I.e., there’s a solution surface, in a 3D space, and the project can go anywhere on that solution surface but not off it. The stool brings in quality as a fourth variable, so you then have a 4D space with a solution hypersurface.
The point is, the triangle drawing can’t show you the solution surface (it’s one dimension short for showing that) and the stool can’t show you the hypersurface (still one short). The pictures don’t let you see the answer which is very disappointing. Worse, the simple drawings for non-mathematical folk encourage one to guess that the solution (hyper-)surface is a simple shape. It’s not for most projects; it’s full of warps and folds and loops.
BTW, for non-software work, isn’t quality treated as part of functionality? Quantifiable quality, that is: MTTF, out-of-spec widgets per 1000, etc.; “fitness for purpose”.
The interesting thing about the stool is that it recognizes that, in software development, quality is separate from the main spec…which is where we go wrong.