Home > Messages from the Ether > Shipping software

Shipping software

Here's an excellent blog entry I found via a /. thread entitled "21 Rules of Thumb – How Microsoft develops its Software." David Gristwood posted it on his current blog (not much content there or on his previous one), but it was originally written by Jim McCarthy. Both work at Microsoft and are apparently project managers. Jim wrote the book Dynamics of Software Development from which the rules were summarized.

The /. discussion gets testy at times (not surprising considering that the article is written by Microsoft employees and purports to tell developers how to develop, we're a testy bunch), but here are some points that resonated with me (both positively and negatively):

(All quotes are only partial. Read the full article to get the complete intention.)

1. Don’t know what you don’t know.

You should reward and treasure those who consistently make themselves aware of the list of relevant things that are currently unknown. Amen, brother. I'm sick of posing a problem to someone and have them reply with confident vagueness. Confront them and the confidence falls away. Just say you don't know and stop worrying that you don't look good to the bosses. F*ck the bosses and just do your job.

(Yes, this is a sore point for me, but trying to get anything done with a bunch of people hiding their ignorance is impossible.)

6. Beware of a guy in a room.

Specialist developers who lock themselves away in a room, going dark for long stretches, are anathema to shipping great software on time. ... They must be capable of performing on a team, making their work visible in modest increments and subjecting it to scrutiny as it matures. Some people find this intolerable, and though there is a role for people of this disposition in the software world, it is not as part of a team devoted to shipping great software on time.

No comment neccessary.

9. Low tech is good.

Shipping great software on time requires that we value an understood solution much higher than one fraught with unknowns.

12. Portability is for canoes.

This is #12 of 21, but it should be much lower if present at all (/. went justifiably conspiracy theory on this one). I aim to write as much as possible in pure C++. This is not because of platform portability but for "domain" portability. If you code file or string functions in MFC and need them in ATL, you're screwed. If you code them in ATL and need them in Win32, you're screwed. Use the pure language when you can and when it's feasible. Portability beyond that is a larger project/company question.

14. Remember one thing: Unity.
15. State your theme.
16. Vary it.
17. Balance it.

He gets very artsy here by basically stealing visual art's principles of design. Not that that's a bad thing, but it's maybe a little abstract for developers.

20. Establish a shared vision.

Everybody on the team must know what they are trying to achieve, what the finished product will look like, what the basis of the product strategy is, and when they must deliver it in order for it to have its intended effect. Contradictory visions must be resolved and unified.

This is as abstract as those referring to design principles, but I like this one. Where's the product supposed to be? What's it supposed to look like? We all need to know our goals.