We know that deadlines drive behavior. That’s why in scrum, and other agile methodologies, we timebox the development with those deadlines. They tell us: Focus on the important stuff, and make sure it’s done properly. Since they are good in essence, let’s see how we muck them up. Here’s the process. We prepare for the
Category Archives: Quality
I usually make fun of the “become a scrum master in 3 days”. I mean, what can you learn in 3 days? Glad you asked. Once a year or so, I get a chance of going through an exercise with my army unit. These few days are plentiful of agile post material. I’ll try to cram
I’ve added a new post in the series of Testing Economics on “Everyday Unit Testing”. Go check it out.
The post, somewhat possessed, now appears on the Everyday Unit Testing site. Check it out!
When we bought our house, we designated one of the rooms as “ the computer room”. It was kind of small office, with a couple of book shelves. Then, with the children, we’ve added more cupboards and shelves and computers. It was no longer the computer room, it was a storage room. “Where is X?”
Remember the days when bugs were just part of life? I mean a big part. If you recall those dark ages, we’ve spent most of our time fixing bugs and introducing others. In our spare time, we got to work on new stuff. Today is different, there are a lot less bugs. So we get
I’m a fan of “House”. I’m currently catching up on the 7th season, where the theme is about truth and lies. For those leaving in a cave with no cable TV, “House” is about a brilliant, misanthropic doctor who runs a diagnostic team in a hospital. In each episode the team dives into a mystery
The first thought I had, reading about the Skype meltdown last week is: here’s another opportunity to score points for unit testing. Nothing like a a single bug causing so much havoc (or silence, in this case) to get developers attention to the catastrophes waiting to happen. But I decided to go deeper. There are
I was asked this question last Wednesday, when I led a TDD open session at the Israeli Software Craftsmanship User Group. My answer: It makes you think before you write code. In fact, next time somebody asks you what TDD stands for, you answer: Thinking-Driven Development. Sure, all the benefits are there: structured incremental progress,
.. and why I’m willing to live with it. Brian Harry has started a series of posts on how he writes code. By the way, he is responsible to manufacture a small software package called Microsoft TFS, so I usually listen to what he has to say, The first posts refer to both his iterative