My friend Andy over at Security Retentive sent me this link to Cigital discussing a twist on the meme of "software does snazzy stuff but it's built like crap."
I want to add two words to the "software sucks" discussion: organizational dynamics. If you start every conversation about software quality, process, security, predictability, etc. with these two words, you'll be on the right track.
Look at technology as just one competency of an organization, then zoom out and look at the whole organization. Now ask "do I believe that in an effort demanding some amount of precision, control, and predictability, this organization can execute?" With many organizations it's immediately obvious that the answer is "no."
If that question seems too vague or unfair, then zoom back in and take a look at specific capabilities inside the company. Look at product management. Look at marketing. Look at HR. Can you keep a straight face while they talk their talk?
Put it this way: think of a company where you have observed "software is crap" in action, whether it's a software product they sell, some line-of-business software they rely on (managing their type of widget or service), or a horizontal product they use to deal with the world (CRM, accounting). Now think of their customer service, or marketing or another department. If you can't take their marketing seriously, or they preach "great customer service" while delivering something else (maybe of great value, but in any case accompanied by awful customer service), then as an organization they are fostering cognitive dissonance at a group level.
The ability to tolerate cognitive dissonance is necessary for most organizations in order to allow flexibility and to prevent entropy from creating constant crises. But more than the "magic amount" of such tolerance just translates to being too comfortable with corporate doublespeak and BS.
In any case, dissonance and software is a bad thing because the machines that run software are remarkably anal. Compilers are adamant about not tolerating dissonance in the scope of a specific application. You can slip some shenanigans in when you're working in a scripting environment, but eventually the gap will manifest somewhere. And when an "enterprise app" is made up of various subsystems and databases, organizational cognitive dissonance leads to "HAL Syndrome" -- the ailment of the computer in 2001 which eventually starts doing undesirable things because it has been secretly given two sets of logically incompatible inputs.
Basically, a necessary (not sufficient) condition for software not to suck is that the organization producing it must have the capability to know when it is being hypocritical or producing conflicting messages, to recognize there is a problem, and to set some priorities which can resolve organizational discontinuities. Without that self-reflective and real self-modifying capacity, the software output may sometimes work, but has no chance of being predictable, reliable, high quality.
Subscribe to:
Post Comments (Atom)
2 comments:
I'm not sure I agree with your diagnosis. I've worked at a number of different places that actually manufacture things. Physical things, things on an assembly line.
They don't often have good marketing departments, reasonable HR departments, people that have any clue.
But, in even the crappiest cases we get better quality control and consistent product from a firm that manufactures physical things than we do from software firms.
Why is this?
- Easier to specify physical requirements that software requirements?
- Easier to manipulate the process and measure what you are producing?
- Easier to measure the final product and know whether it actually worked?
- Lack of unqualified clowns who think they can do the job, fool people for a while, but are actually producing junk?
I'm not which of these it really is. But assembly lines don't build themselves, physical goods don't generally get built by people with no training and experience, but software does.
McDonalds has structured their whole work environment around getting consistent product from essentially unskilled labor.
Airlines however put people in the pilot seat that has a demonstrated track record of knowing what they are doing. Has passed a bunch of tests, has consistently demonstrated abilities.
I feel sometimes like we want the airline pilot, but companies think they can develop software on the McDonalds model...
At last McDonalds has a way of measuring when the hamburger got cooked right.
I argue that software development is "susceptible" or "corruptible" by org cognitive dissonance. You are showing that delivery of hamburgers or airline flights can be made less corruptible.
But I disagree if you're suggesting that the same procedures by themselves can help software in this regard. Take measurement of the output, for example. It doesn't fail to help because it doesn't work; rather it's compromised by organizational factors. There are too many social vulnerabilities -- the software process itself is inherently "soft" in a group dynamics sense, so it gets reshaped by the org's internal disagreements.
To use an analogy, certain kinds of businesses are rapidly corrupted by a corrupt government or organized crime. They are attractive because they have a certain amount of "flexibility" that can be exploited (just like IT).
You are right that externalities (to the group) can work against this. E.g. the FAA's requirements for pilot certs and aircraft maintenance go a long way toward fighting the airlines' org problems that make them want to cut corners on maintenance, employ fatigued pilots, etc. And you're also right that real liability would serve the same external role.
Post a Comment