01Dec 
If you don’t sleep as well at The Benjamin Hotel as you do at home, Andy Labetti, General Manager for The Benjamin, will give you a free night’s stay. A good night’s sleep is non-negotiable. The Benjamin’s ‘Sleep Guarantee’ ensures that everyone who stays at the hotel walks away well rested or gets their money back. If a guest is dissatisfied with his or her sleep at The Benjamin, all they need to do is contact the front desk, and the hotel will refund the cost of their night’s stay.
And those aren’t just some words slapped on a hotel brochure. The Benjamin has gone to extraordinary lengths to back up the guarantee of a good night’s rest in New York, “the city that never sleeps.”
Read more »
20Nov Are software companies knowingly releasing buggy, defect-ridden software intentionally? In the words of Sarah Palin, “You betcha!” I’m not saying that they release bad software with malice. It’s more about the cost equation associated with fixing the defects. I was talking with Tom Poppendieck at the ADP Conference last week and here’s how he explains the costs associated with fixing defects:
- Fix it now: The effort to fix a defect as soon as your developer types the wrong code is pressing Ctrl-Z (UNDO!). Cost is essentially ZERO. And if you’re pair programming, you’re very likely to catch the defect at this point.
- We’ll fix it next week: The cost of fixing a defect one week after it happens is a fix on the incorrect code, plus the time refactoring one week of code developed on top of the bad code. Probably not too much, we’re talking about a few hours max.
- We’ll fix it at the end of our iteration: The cost of fixing the defect after a two-week iteration is probably about twice as much as after one week. Cost is up to one day.
- Don’t worry, we’ll get to it later, we don’t have enough QA budget for it now: Here we are 6 months later at the release date. The cost of fixing one error in the code is now exponential if you have to refactor 6 months of code based on the initial defect. Cost: Potentially HUGE!
Read more »
06Nov 
OK, so if you didn’t guess it, quality software has been on mind a lot over the past two weeks. And why shouldn’t it be? It should be foremost in all of our minds (if you’re in software development). It’s what our customers expect and demand. They don’t want buggy, defect ridden software. Unfortunately, things like software quality and testing are usually seen in a budgetary/cost light instead of the customer satisfaction light. I’ve beaten this point to death already and by now you already know that in my opinion customer satisfaction is paramount. And, anything we could do to improve the quality of our products should be pursued vigorously.
We’ve discussed the CIO commitment to quality already, and we’ve looked at ways to tightly couple QA/testing into our iterations. Today, I started thinking about other places in our development cycle where we could really show great strides in improving software quality. I think I found one: Lets take a look at pair programming. The first thing most people say when I mention pair programming is “Why would we do that? We’ll have two developers doing the same work that one developer can in the same amount of time!”. OK…fallacy number one: This simply isn’t true. Studies have shown that pair programming doesn’t reduce productivity by 50% as implied by the previous statement. In fact, pair programming reduces productivity by only about 15%. WHAT!!!! Yes, I admitted that pair programming reduces productivity. But, the 15% loss in productivity is made up for by gains in reducing defects.
Read more »
05Nov In the past few weeks I’ve been asked about and have been considering exactly how to fit QA and testing into a two week iteration. A primary concern of the folks I’ve been talking with is that QA’s and testers on an agile team have nothing to do at the start of an iteration. The second concern is that we can’t keep writing new code up until the last minute of an iteration if QA is to adequately test the code, and as such, what do the developers do at the end of the iteration. Of course, the underlying concern in both of these cases is keeping the QA’s and the devlopers effectively utilized during an iteration. Software quality always seems to boil down to a utilization/cost equation doesn’t it? Well, after giving it some thought, I think I’ve come with a basic schedule for QA’s and developers over a two week iteration. Here’s the plan:
Read more »
