Table or Booth?

No 'Team' in 'I': Going Solo with WACD

To continue from an earlier post on the WACD methodology, here are some tips for keeping the pesky 'team' concept from eroding your development sovereignty.

First off, developing applications in teams runs the risk of contaminating your line of thinking with inferior logic.  The fewer people on your team (ideally, just you), the more freedom you'll have to solve problems the right way. 

Sure, developing in isolation may lead to duplication of efforts in your IT organization but that's OK - IT organizations are full of redundant waist and it's not your job to fix it.  Besides your solution will undoubtedly be superior to your look-a-likes.  Everyone will benefit by learning from your example.

Development teams like to second guess each other by doing code reviews.  This is just a crutch for weak developers with no guts.  Be smart and write the code perfectly to begin with.  As you already know, writing near-perfect code eliminates the supposed benefit of second-guessing weasels. 

In the rare case where factors beyond your control caused you to write a bug, you'll be the only one who'll understand it.  Not only is this is great for your job security but it ensures a peaceful debugging process where you're not constantly being asked questions that begin with "Why did you... blah, blah, blah."  So friggin annoying.

Last but not least, teams often talk of 'camaraderie' and 'morale.'  My advice here is simple:  Camaraderie is for commies, morale for pussies.  Don't be either.  Clint Eastwood didn't ride into town with a Cowboy Support Group and neither should you.

Earnings-Based Consumption

We cannot spend our way to good economic health, even in the short run.  We have to produce.

John Stiglitz, Chief Economist of the World Bank from 1997 - 2002 took callers on CSPAN this morning, one of which was a democrat who suggested (paraphrasing), "With the economic downturn and the tax payers being the problem, with the bad mortgages and such, why not just give every American one million dollars? Then people would spend money, helping businesses, and letting people keep their houses and jobs."

Why stop at one million?? Why not 10? How about 100 million? We'd all be set for life.

I'm all for consumption as a important part of market health. However, the problem with consumption based on money given versus money earned is that, when given, you have no skin in the game. No risk taken. This changes everything. If you lose it all because of a bad decision, oh well. 

With money earned, you have a vested interest in not seeing it disappear. With money earned, you do your best to get the maximum value you can for every penny. This kind of incentive works.  Money-given based consumption eventually reduces productivity to point of total dependency.  This is socialism and, as history shows, has a strong track record for destroying markets.

Enterprise Bearware

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.

Hurricane of Hope

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.

On Career Choices...

"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:

• How to Keep Your Job
• Discussion with Dave Thomas and Andy Hunt
• Advice from Monster.com
• Paul Graham: Hackers and Painters
• Keep Offshoring From Taking You

Standing Firm in Software

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?   

Agile vs. RUP - Practicing Resonance: Part 2

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:

• document-centric - they labor to produce detailed documents whose prescribed purpose is the necessary outcome of many of the activities in the overall process
• perfectionists - since they move only once from phase to phase, it is imperative that the artifacts (code, documents, etc) they produce be perfect.  In theory, iterating within the phase should allow for mistakes and trend towards more and more perfect artifacts.
• cautious - RUP practitioners cannot afford to design or implement a mistake because it will destroy the integrity of the overall plan that was established during or even before the first phase.
• independant - some might unjustly say "isolationist".  The truth is, they trust the RUP process 'framework' within which they expect the right information to be available in order to  get their specific job done.  Well defined interfaces between all the components, allow each person to work in relative isolation and then later plugin their individual pieces.

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:

• customer focused - they insist on having the customer highly involved in each aspect of what is being produced.  The customer's regular feedback is immediately incorporated into the development effort, even it if means significantly changing what had already been produced thus far.
• real - they don't try to make guesses and purposeful keep the scope of their efforts small.  They explore often to get the information necessary to continually make small steps forward.
• intuitive - they rely on experience to guide them through the process and try to minimize activities that 'just don't make sense' for the task at hand.  If a comprehensive design specification doesn't get the job done, then they don't attempt it
• communicators - they try to 'peer program' as much as possible.  They try to convene strategic and tactical thinking in the same activity by having someone 'drive' while their peer 'navigates'.

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!