If you've ever been a programmer in a bureaucratic environment, you've surely thought of yourself as the spawn of the red-headed step child and the family mule.
Performing heroic acts in a bureacracy is patently a bad idea. Why? Because if you've jumped the Grand Canyon on a motorcylce once, surely you can do it again or anything else for that matter. The bureaucrats are only half the problem here folks. Our damnable need to please (or to not rock the boat) is the other half of the issue. You're a programmer right? That must mean you can do anything. Time to start disabusing some folks of some faulty notions. Expectation management is a must. Every boy or girl programmer out there wanted to be Superman or Wonder Woman growing up right (or some other ridiculously clad character with amazingly unrealistic physique)? Why, because we were/are geeks. We were/are social outcasts because we were smarter or more creative or something than everybody else and they loathed us for it. Time to grow up and put the cape away.
While we are at it, we might think about passing on some understanding about what it takes to do our job, because the higher ups haven't a clue, and its more because we over-respected the pecking order and never told them just how much it takes to do what we do than them being self-absorbed.
Secretaries don't get enough respect. They keep the world from being overrun by incompentent managers. They don't get appreciated enough, why should we? Why, because for the most part, secretaries are support personal. We are production assests. You can't speed up the auto line any more that it already is Mr. Ford, and it is already going too dang fast. Managers can see into the daily lifes of their secretarial staff and at least try not to push them too hard. As far as most of them are concerned, designers, IAs and developers might as well be performing black magic.
What is grossly needed here is some education about what it takes to design web pages, architect information and build web apps, and no Mr. Boss Man I can't, "Just build one of those CMS thingies from scratch." At least not for what you pay me. :)
Documents don't kill understanding. Documents in our American culture kill understanding.
Why do people who specialize in bending words forget to transfer meaning?
The problem with lengthy requirements documents are
- They never tell the whole story no matter how much you write
- The users of these documents (programmers) never ask any questions because its all right there in the spec
- The writer of said document never questions if his intent was understood because its all right there in the spec
Conversations leading to acceptance tests are better for specifying a project because:
- Conversations don't inspire us to use 25 cent words that even we are fishy on the meaning of
- You are more likely to ask a question of a person than you are of a piece of paper
- Understanding is best reached through a series of questions asked and answered than a document read over ten times
Dan say's its ok to use functional specs and use cases to organize your thoughts. I agree with him if these things are for your eyes only. I wasn't born in 1950, and I haven't watched "Tron" enough times to be able to think in terms of "the system shall..."
In Joel's perfect world, functional specs can be used to communicate design. Joel, I think you may be the only person on earth who can pull this off.
I like user stories and acceptance tests for communicating design because:
- They are light-weight enough not to kill conversation
- They allow you to focus on only what matters right now
Aren't there published studies to the fact that most human brains can only deal with 3-5 pieces of information at a time?
This does not mean that I am advocating throwing out design and design review. What is does mean is that I strongly advocate doing Just In Time Design.