January 30th, 2006
You know what I like about the way software is being designed at this new place I am contracting for? There is no "wheeling and dealing" for features. The marketing requirements are treated as the Word of God, and so there is a simple test: Do they have time to include feature X? Yes or No.
And so it goes that a fairly new blush on an existing product is being laid out in a language of certainty--not through acts of bravado by a single project manager sending emails at 3:00AM trying to see how many of the things he just thought of this moment can get squeezed into the software by some arbitrary date. The truth of that last workplace is that I witnessed all the real development come to a grinding halt over a period of about six months, and watched some really truly amateur people ooze in and start talking out of their assholes as though they had a clue what they were doing.
The people around them took their piles of total bullshit and did their best to interpret their stupidity. The result was a half-designed, half-blind-engineered single customization of a product that would otherwise normally be highly customizable. It's like this: The product had scripting and customization properties, as well as a form control application attached. You could make it act and behave like any word-processor, specialized content-entry application, database front end ... heck, I was even on my way to creating a Space Invaders game using this application (and its accompanying customization environment). You can think of it like word-processing templates: You could make a template to do anything, restricted only by your imagination. Then the amateur people took those valuable software assets and decreed that they should all stop being customizable and instead behave only one way. Like putting a car onto train tracks: Suddenly the steering is pointless. One template, one size fits all.
This all happened because, prior to that, developers started quitting in droves, disliking the amateurs they had to work with, taking years of internal product knowledge with them, and pretty soon there just weren't enough qualified developers working there any more to effect more than superficial changes to the product. Nobody knew enough to make really detailed mods.
Here's an example of how to create staff-quitting stress in your workplace:
Hypothetical sentence in an SRS: "The interface should allow users to easily enter their statistics and then quickly return relevant data."
Crap. Utter crap. How can someone look at that and know what to do? How can QA know what to test for? How can Documentation write docs based on that? The answer is that the developers guess, have to rework repeatedly while the SRS-writer continually rejects the software until the developer has guessed what's on his mind. QA can't make test plans until they actually see the interface, and Documentation can't start writing docs until they have actually seen the interface ... spending overtime in the last two weeks to catch up. Bad process. Stress all around. People get unhappy and start quitting and writing nasty things into their blogs.
Better: "John enters his time, percentage, and volume ratio into three text areas on the dialog box (see mockup, Appendix A). He clicks OK. Within five seconds, an Assessment Report is displayed on the screen showing a) Percent per second, b) Total mass transfer, and c) Dollars per mMol (see mockup, Appendix B for example report)."
People don't usually write that second kind of requirement, because it takes time and effort. You can't write something like that the night before a deadline. Worse, other people will have to review it and God forbid you should be subjected to an edit or two. Heaven help the SRS-writer's bruised little ego.
So you know those intolerable people I was talking about? The ones whose lack of process drove away the quality people, and then the ones who poorly designed themselves into a corner? They created all kinds of workplace stress through vaguery and imprecise language in their so-called design documents, then congratulated themselves when, through heroic measures, the people around them were able to patch together something marginally functional, despite the crappy documents that bore no relationship to requirements.
But many of the quality people got stressed out over time. And they quit. And so went even the ability to effectively modify the software.
Then the amateurs got together and started writing more documents that they euphemistically called "design" or "requirement" documents. And still more imprecise, uncertain language to generate even more stress among the few remaining talented people being called upon to try and read the document-designers' minds. The stress is made all the more palpable by the fact that the people carrying out the implementation are dozens of IQ points smarter than the so-called designers, and in many cases years more experienced. That alone is a huge source of stress.
Well, it was the killer for me, and many of the people I talk to about this marvel at my longevity: They wonder how I was ever able to hang on for as long as I did. I tell them that it was the traveling I got to do: Trips to big customers in interesting places in the US. The hotel rooms and airflight I could take or leave, but the training I did and the people I met were worth it for a year or so.
* * *
But that has all ended with my new directions. I am my own boss; I have my own company now and I contract out to the highest bidder. I am both the prostitute and pimp in my new venture, and so far it has yielded *very* satisfactory results.
Like, back to what I started with about the place I am currently contracting with: They hired me for the better part of a year to work with their Requirement Docs. I can read them, I can create docs ... and there isn't even an interface to look at yet! Now that is professionalism and decent process. I go home knowing if I am on track or not, if I am within the required time frame or not. I sleep with a smile on my face knowing at least 75% what the software will look like at beta, and I go to meetings with a quick jump in my step because I know I won't hear about some new features the Project Manager just thought of. (See, he already thought of it months ago as a natural part of the discovery that comes from properly writing an SRS).
I picked a flower and smelled truth in it,
The birds sang a song of wisdom
And I smiled
Rate my blog - Sign my guestbook - Email me - Go back to index