It’s winter here in Massachusetts, and we’ve had lots of snow, ice, rain, snow, ice, snow, ice, rain. All that freezing and melting plays havoc with the roads. We have lots of potholes, and the local and state governments are busy doing emergency repairs all over the place. (For those of you who don’t know […]
It’s been a heck of a week. My office is in my basement (a walk-out basement with lots of light–it doesn’t feel like a basement). Earlier this week, I thought I had a leak in the foundation–there was a small damp spot in the rug. I called the basement people to make appointments. Of
Well, all the comments on my No More Bugs post got me thinking. To answer a few comments here and elsewhere, I’m not trying to blame developers for being human and making mistakes. When I was a developer, most of my mistakes involved code. As a manager, most of my mistakes were in my dealings
During an email conversation last week, I suggested that my client change his naming of “bug” to “defect.” He asked why. People don’t create bugs, but people create defects (or problems or faults). Bugs crawl in or fly in from the outside, when you’re not expecting them to. But we expect defects and problem in
I was sitting on the couch was organizing a database last weekend, with daughter #2 sitting next to me. I was creating a script to go through each record removing a field’s contents and adding new contents to another field. Not a difficult thing to do. I created a loop, and daughter #2 said,
I’m familiar with managing defects by severity (how bad the problem is for the user if the user encounters the problem), and by priority (what’s the business value of fixing this problem), but I had lunch yesterday with some folks who use frequency of occurrence to also manage defects. They started this because they
I have several accounts with a credit card company: two cards and a merchant account. They don’t want the expense of printing monthly statements for the merchant account, so they sent me a letter to enroll my merchant account in online statements to avoid the paper charge. In my default browser (Safari), I attempt
I’ve had several discussions about maintenance in the past few days. I’m beginning to think I have a different definition of maintenance than other people do :-). For me, maintenance is fixing problems in code. Maintenance is short, small, well-contained and code-based, and should be fixed by the developer(s) who created the problem. So
In the last few weeks, several people have asked me how much rework is normal. Well, if you’re working in a test-driven development environment, you probably have very little rework. My estimates for the few real test-driven projects I’ve seen is that they spend about 10-15% of their time on rework (finding problems and
Bloglet subscribers saw two posts from me Friday. They saw the post I published *and* the post I saved as a draft. Surprised me. Since I know about this feature, I’ll work around it, and compose future drafts somewhere else. This isn’t a big-deal problem for me. But it was a surprise, and a