Archives / 2004 / March
  • How to Shoot Yourself in the Foot with Code Coverage? (Part II)

    One of the phrases I quite often use is “honest something“. What do I mean by this? First of all I believe that everything what is worth doing should be done with the highest quality possible. Secondly I believe in doing things “by the book“, but this shouldn't be confused with blindly following orders or having very fixed and limited thinking process ;-) The best way do explain this is to give a concrete example:

  • Writing blog entries is no different from managing software projects

    Actually most things in life are like managing software projects: you need to understand how much time (or any other resources) you’ll have for the tasks you want to perform, what’s the priority of these tasks, in what order they need to be performed etc. To set myself into the habit of writing at least two posts during the week I finally decided it’s time to publish the schedule for upcoming posts. Most human beings have different kinds of fears: some people are afraid of dark, some people are afraid of flying etc. One of the things I’m always afraid of is not meeting any of the dates I promised to meet (feel free to analyze me now) ;-) So, hopefully publicly telling that by date D I’ll post blog entry on subject S will force my subconscious to schedule my time better. Here are the subjects I plan to write about with the date, short summary, and title:

  • "The average software developer reads less than one professional book per year...

    ... (not including manuals) and subscribes to no professional magazines." This is actually from DeMarco and Lister, Peopleware, 2d Ed, 1999. I don’t have the book in my hands currently to find out on what page it was, but I stumbled across this quote while reading "Professional Development Handbook" by Construx Software which is Steve McConnell’s company. If you care about developing yourself or your direct reports / organization then this is IMHO a good document to read.

  • How to Shoot Yourself in the Foot with Code Coverage? (Part I)

    Usually after every milestone or after every version of some product most of the groups have something called postmortem. Encarta Dictionary defines postmortem as "an analysis carried out shortly after the conclusion of an event, especially an unsuccessful one." This doesn’t of course mean that every time you have postmortem, something went wrong. Quite the opposite, analyzing the positive experiences and writing down keys to success have the same benefits as learning lessons from negative events. Most people have unconsciously their personal postmortems daily thinking about recent events and stuff ;-) This is my code coverage postmortem.

  • Do you have a personal coffee machine at work?

    It's quite late in the Seattle area now and I'm in the process of writing a first draft of a blog entry about how to misuse the code coverage. We've learned some lessons during the last year or so in Speech Server team and it's a good time for the root cause analysis. Of course it's also always easier to criticize something than do it properly yourself ;-) While analyzing our failures and successes I drink coffee to stay mentally sharp and suddenly realize that I actually need to write something about coffee.

  • Bastard Code Reviewer from Hell

    When somebody will ask about the relationship between me and Un*x then I would have to admit that my alma mater was/is rather the Un*x place than Microsoft place. This also means that I “grew up professionally” while reading all these stories about Bastard Operator from Hell ;-) Times have changed and now I’m not reading fanatically Richard Stevens’s books anymore and honestly I don’t even remember the last time when I wrote any code that used fork() system call in it ;-) The frightening image of BOFH is stuck in my memory though.

  • Past-due software projects, can something be done about them? (Part I)

    Anyone who has ever read CHAOS report by Standish Group or participated in at least one software project knows that Murphy’s law works – if anything can go wrong, it will ;-) Like Fermat’s Last Theorem puzzled mathematicians for centuries, the problem of estimating correctly the time to complete any given software project has been extremely difficult to solve, although most of the people in software industry battle with it every day. In spite of the fact that Fermat’s Last Theorem has been finally solved and mathematicians are cheering, when it comes to delivering software on time, it’s still very hard to see the light at the end of the tunnel. Being also a chronic pessimist (though I rather prefer to be called a skeptic ;-)) I doubt also that we’ll find some silver bullets anytime soon. To summarize: when software engineering as a separate discipline was established, things were bad and they aren't much better now ;-(

  • Another pitfall to avoid while using assertions

    On the first look this seems like a perfectly legitimate and reasonable code, but let’s not forget what GetLastError() does ;-) Per MSDN: “The GetLastError function retrieves the calling thread's last-error code value.” Is the last error code generated by “SomeWin32APICall()”? No, _ASSERTE does lots of stuff internally, including calling some other Win32 functions, so the original error code is lost unless you store it away somewhere.