The price customers pay for software and the level of usability they get with that software is inversely proportional. As long as it solves a big business problem or two, it doesn't matter how easy it is to actually use the stuff.
If you haven't seen Robert Tracinski's controversial piece about the New Orleans disaster, check it out. Whether or not you agree with his position, it's atypical, intelligent commentary on the matter.
"One of the most valuable things my father taught me is an old Yorkshire saying: where there's muck, there's brass. Meaning that unpleasant work pays."
- Paul Graham, Why Smart People Have Bad Ideas
A few other useful programming career-oriented links:
Dr. Tony Evans once said, "When it comes to taking a stand, too many of us have our feet planted firmly in mid-air."
He meant it in the context of knowing your faith and standing by it when, maybe even especially when, it's not popular. So true. It reminds me of my beloved U.S. Marine Corps motto: "Semper Fidelis," which means always faithful. But that was another time and place...
It's worth considering that standing firm applies to many things, not excluding software. So how are we supposed to do this, exactly?
Procrastination murders possibilities. This is partially explained by the 'primary path' phenomenon. Our primary path is a chain of activities that each support whatever it is that truly motivates us, true motivation being the root of all primary path activities. Primary path goals and their activities have the best chance of getting done. Why? It's simple, we want to do them.
An erotic dance club owner in Idaho charges $15, two nights a week, for what he calls "Art Club Nights." To skirt laws forbidding full nudity, he gives patrons a pencil and a sketchpad, allowing his art 'subjects' to legally take it all off.
It's an interesting case for highlighting a fundamental question: Since clothing can't be legislated, where should personal liberty end and government begin? Depending on your perspective, this line often zig-zags and is hard to see. Yet, if we look through the 20/20 lense of history, these 'best practices' are clearly relevant:
Since erotic dancing promotes a mentality that treats woman as souless sexual objects, I'm not a fan. What's more, despite its instinctive effects, watching it seems pathetic for reasons I can't quite figure out. So, you won't see me in Idaho 'dance' clubs. Even so, given the criteria I list above, the anti-nudity law in the Idaho nightclubs is a bad one to begin with. Even Mrs. Potatohead would agree with that.
While Agile and Unified Software Development-style processes claim to be iterative and adaptive rather than defined and predictive, they both have limitations when it comes to efficiently producing software in medium sized teams. This particularly true when these span multiple geographies. However, they can both teach us how to achieve what I'm calling 'resonance' (see part one of this series).
Note that the Rational Unified Process (RUP) is the official IBM refinement of what is essentially the Unified Software Development Process (Jacobson, Booch, Rumbaught). As background, I'll first proceed with this embarrasingly incomplete review of the Agile and RUP practices.
The RUP is "use-case driven, architecture-centric, and incremental and iterative". Each iteration is part of four overall 'phases': Inception, Elaboration, Construction, and Transition. Iterations occur in each phase. Activities in iterations are focused on one of the four activities: gathering requirements, analyzing, designing, implementing, and testing. Each of these activities place a more or less important role as the project moves from phase to phase. As Craig Larman points out, RUP is not the dreaded 'waterfall' approach. It's the mis-application of its myriad of optional workflows and documents that tend to promote that illusion. Here are some personal observations about how it works in practice. RUP practitioners are:
Agile development is more of ethic than a process (the founders refer to it as a "manifesto"). To get a feel for what a completely "Agile" process might look like, take a look at Xtreme Programming (XP). In essence, to be agile in software development is to quickly and appropriately react to new information in the development cycle in a way that best satisfies the customer. To best make this happen, Agile practitioners are:
The "independant" and "communicator" characteristics in each of the previous lists are the ones most worth focusing on in order to achieve resonance. Part three will consider RUP and Agile practices' techniques for dealing with independance and the basic communication issue, the very heart of resonant practice. Most importantly, we will consider exactly what this means for geographically disperse teams. Stay tuned!
