Madness to the Method

My division is one of many. Ours is currently the only one putting method to the madness, hiring Analysts and Project Managers, documenting all the work that's done, ensuring all the code gets tested, and making sure the customer is happy. We've learned the hard way that when Timmy wrote Our Beautiful Code, Our Beautiful Code is bricked the moment Timmy walks out the door. Too many shops rely on Timmy keeping it all straight in Timmy's head, and there are many developers who thrive on this idea:

"Documentation is nonsense, and asking people questions gets in the way of writing software."
"They'll like what I build because it's not pen and paper."
"They'll use what I give them because they have no choice."
"...And they'll see that I Am the God of the Code."

There's an argument for this approach: it usually starts with, "We haven't got time..." and ends with, "...because everything's on fire!"

People love "the quick win." Developers love it especially because they get bored. They are creative people, and having to labor at the same thing day after day requires a patience and mind for tedium that most other humans lack.

Management loves seat-of-the-pants solutions because they solve a problem quickly. They don't love them when they break. Often another rickety contraption is rolled out while the broken one is trundled backstage to be dismantled.

No one in technology plans very far ahead: that would be silly. Isn't it amazing that Windows XP lasted for 6 whole years? I can tell you now that while it is a nice idea that a software application might still be in use 6 years from now, 10 would be absolutely out of the question. I know without consulting my crystal ball that a user trying to use today's system a decade later is going to curse my name and start casting aspersions on my ancestry.

So why document? Why bother writing it down?

- To get it right before you start down the road
- To build something useful
- To fix breaks without having to track down Timmy
- Because like it or not, you and yours will be supporting this

The Project Manager faces a balancing act between customers and development: imagine your Project Manager going about her daily routine as somewhat like The Cat in the Hat, teetering a goldfish bowl atop an umbrella whilst unicycling. In the midst of this, two important Things must not run amok:

Thing 2 is that the customers must not be bored while you're getting ready for The Great Show that is their product. Don't make them re-read all your use cases and have meetings because you think meetings make your project seem important. Don't use technical jargon to make you seem smart, or go on about this great new feature that Technology X is going to offer the developer.

Thing 1 is that the developers have to be given something of value, then shown--by way of your documentation--that the streets ahead have been paved with gold. I've had more than one developer fuss and struggle with my methods, only to suddenly see, right towards the end of development, that I've magically given the customers training materials and user guides that cut down on the number of phone calls and e-mails...and at the same time I've given the developer a road-map to get back into their system if things go wrong. Or--better yet--hand it off to Junior Developer without having to sit behind him and do half the work using only the power of speech.

The next step I wish to undertake is to empower the client: the more changes to their application that they can apply without putting in a support ticket, the better life gets for everyone.

Without documenting how the machine works, none of us would ever be able to sandbox the client so they don't get themselves stuck.