Archive

Posts Tagged ‘quality’

The WTF? Metric


Lo and behold! It’s the monstrously famous iron triangle:

Iron Triangle

Even though all three critical project factors should be respected equally, BD00 put “schedule” on top because the unspoken rule is “schedule is king” in many orgs.

Everyone who’s ever worked on an important, non-boondoggle, project has heard or spoken words like these:

“I’m concerned that we’re exceeding the budget.”

“I’m afraid that we won’t meet the schedule commitment.”

But how many people have heard words like these:

“I fear that our product quality won’t meet our customer’s expectations.”

Ok, so you have heard them, but stop raining on my parade and let’s not digress.

The reason that quality concerns are mentioned so infrequently relative to cost and schedule is that the latter two objective project attributes are easily tracked by measuring the universally accepted “money” and “time” metrics. There is no single, universally accepted objective quality metric. If you don’t believe BD00, then just ask Robert Pirsig.

To raise quality up to the level of respectability that schedule and cost enjoy, BD00 proposes a new metric for measuring quality: the “WTF?“. To start using the metric, first convince all your people to not be afraid of repercussions and encourage them to blurt out “WTF?” every time they see some project aspect that violates their aesthetic sense of quality. Then, have them doggedly record the number and frequency of “WTF?”s they hear as the project progresses.

Before you know it, you’ll have a nice little histogram to gauge the quality of your project portfolio. Then you’ll be able to…, uh, you’ll be able to… do something with the data?

WTF Histo

Yet Another Nit

January 25, 2012 Leave a comment

Programming in C++, I “prefer” composition over inheritance. Thus, for that reason alone, I’d use “ComposedLookupTable” over “InheritedLookupTable” every time:

In addition, since (on purpose) no STL container has a virtual destructor, I’d never even consider inheriting from one – even though those who do would never try to write this monstrosity:

Of course, this can be seen as yet another childish BD00 nitpick. But hey, what else is BD00 gonna do with his time? Solve world poverty? Occupy the org?

Quality is in all the freakin’ details, and when you see stuff like this in product code, it makes you wonder how many other risky, idiom-busting, code frags are lurking within the beast. But alas, where does one draw the line and let things like this slide?

As a final note, beware of disclosing turds like this to their authors; especially in mercenary cultures where everyone is implicitly “expected to” project an image of infallibility in order to “advance” their kuh-rearends. If you can excise turds like this yourself without getting caught, then please do so.

Categories: C++, technical Tags: , , ,

Process, Passion, And Quality


Naive managers (usually those who get drunk on large quantities of 6-sigma, CMMI, ISO-90XX, EVM, and/or PMP kool aid) tend to think of the correlation between process and quality like this:

This cause-effect diagram can be read as “more process imposition leads to more quality; less quality leads to more process imposition“. What’s missing in this simplistic diagram? Could it be something that represents the human element?

In the blarticle, “Process kills developer passion, James Turner writes about the human element of “passion“:

…passionate programmers write great code, but process kills passion. Disaffected programmers write poor code, and poor code makes management add more process in an attempt to “make” their programmers write good code. That just makes morale worse, and so on.

If you believe Mr. Turner, then the cause-effect diagram for process and passion is a self-reinforcing loop that may snuff out passion over time:

So, what about the relationship between passion and quality? I think that many would agree that it is thus:

When we integrate the two models above, we get….

Moving from left to right, and then from right to left we read that:

an increase in process triggers a decrease in passion, which triggers a decrease in quality, which triggers a further decrease in passion, which triggers an increase in process imposition. Round and round we go.

If we assume that “passion” is an integral player in the system, but hide it in the above diagram to simulate a common managerial blindspot, the end to end process-quality cause-effect diagram emerges as:

If we compare this derived result to the first naive manager mental model which doesn’t include the messy “passion” element, what’s the difference?

Product Development Systems

April 24, 2009 Leave a comment

The figure below shows two (out of a possibly infinite number of) product development systems. Which one will produce the higher quality, lower cost product in the shortest time? Would a hybrid system be better?

product-dev-systems1

Follow

Get every new post delivered to your Inbox.

Join 454 other followers

%d bloggers like this: