Thursday, April 21, 2005

Sick Day/Game Day

Strep throat is no fun. But I think I caught it early and I'm not hurting too badly. Susan has been awesome taking care of me. Last night she made oatmeal cookies for me. This morning I had to work, and she made and brought me coffee. She's the best. I can't believe she loves me as much as she does. I don't ask questions anymore; I just accept it.

Game time:

This game reminds me of a time when I was doodling spaceships when I should have been studying.




This one I played as a text-based adventure years ago too. And with the current hype (or lack of) for the new movie . . .


Monday, April 18, 2005

What makes a requirements document

A Slashdot reader asked what made a good requirements document. The following response was more true to what I've experienced. I thought I would share.
  1. Talk to the various stakeholders. Hold meetings. Get everyone's input on what's the Right Thing To Do.
  2. To the degree these ideas are not the Wrong Thing, do them, even if they're less efficient than you'd like, or are less fun to code. You're going to be giving them a prostate exam with a cheese grater in a couple of steps, so soothe their egos proactively by letting their ideas make it into the final product.
  3. Take the draft to your dev team. Circulate copies, have everyone read it, then have a short meeting--one hour, tops--not to discuss how to do things, but which parts of the design will require a lot of experimentation and fiddling.
  4. If your dev team doesn't already have someone fluent in Corporate Weaselspeak, then get one.
  5. Give your translator this sentence: "We will use our magic powers to accomplish this part of the design document." Have him turn it into a five-page monstrosity that lets every stakeholder think these difficult parts are going to be done their way, without really committing your dev team to anything.
  6. Take the weaselized design doc back to the stakeholders. Your Corporate Weasel's job is to make the stakeholders sign off on it.
  7. The easy and routine parts of the job get done the way the stakeholders want, assuming their way isn't completely braindamaged. The hard parts of the job will be solved by your development team's magic powers. It's right there in the design document.
  8. Bring the project to completion. As you're doing the hard part, write This Is How It Really Works documentation for engineers who are coming after you.
  9. When your project is ready for handoff, make sure to praise the (easy, routine) parts for which you used Marketing's ideas of how the software ought to be written.
  10. Gloss over the fact that you did the hard part via magic powers. The other stakeholders probably don't care. You're giving them a beautiful bullet point for their end-of-year performance eval. That's what they care about at this point.
  11. Move on to the next project. ...

Is all this weasel office politics? Damn straight. On the other hand, it's weasel office politics meant to shield your development team from unnecessary weasel office politics. As much as we hate weasel office politics, sometimes it's necessary.

Site Updates

I'm oftentimes fascinated by the google ads on some of the blogs I read. I don't think that I'll often generate enough traffic to make much money of them but I am now part of the many using AdSense by Google. I'm not asking you to click on the links, but if you see an interesting ad associated with a post, drop me a line.

I've also added MapBlog. You'll see a map of where I am and other registered blogs in my vicinity. It was developed by a MapPoint developer at Microsoft. If your in the area, drop me a note; we'll discuss the topic of the day.

Current reading list

Red Storm Rising - Tom Clancy: I just started this again. I was in the mood for something light and Clancy always fits the bill for me.

Asimov's Guide to the Bible - Isaac Asimov: You want the history around the Bible. This is your book. The book is a bit dated, but when one writes about a book 2000 years old . . . the dating is not so much an issue.

Island of the Day Before - Umbreto Eco: This is the book on the back burner. I'm reading it, but it's hard. I really enjoyed The Name of the Rose and Baudolino by Eco. Interesting, fun reads. With a taste of European history thrown in. I've started Island a few times over the last few years. I can never finish it. It just goes on . . . and on . . . and on. The only other books I have started and not finished are Zen and the Art of Motorcycle Maintenance and some mystery about a female FBI agent that my sister gave me. I don't remember why I quit on Zen. I think it was because I was expecting so much more than it was. The FBI chick book spent more time on feelings than on suspense. Ugh.

Next on the list: If on a Winter Night a Traveler by Italo Calvino. It was recommended by my cousin Lisa, whom I love. After that I think will be System of the World by Neal Stephenson. The first book in the series rocked, the second was enjoyable. I'm hoping that Jack plays a more prominent role in the third.