5 Things “House” Can Teach You about Fixing Bugs

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 – what does the patient have? How can we treat him?  On their way, they try different methods to prove or disprove their theories.

Which, of course, made me think about development and testing. I bet you see the resemblance too. No? Let me count the ways.

The patient has a bug! 

The patient is a legacy system. It works mostly, but then it shows certain symptoms. Dr. House is called to fix the bug, and as we do, he starts out checking around the symptoms – what is affected? What’s the impact? And above all – can we fix it?

We have a the theory

“Run the tests” House says. Diagnostic tests, unit tests – they are all the same. They prove our theory – a function (bodily or coded) produces results under known conditions. When the test passes, we know we’re right. Or the other way around. But then…

Another symptom appears…

This one disproves the latest theory. “We’ve missed something” says House. The tests are passing, but the system is still failing. The team goes into an agile loop of theory-test-another symptom. In addition, the team tries to get more information from the patient or family. But:

“Everybody lies”

Says House. And everyone who looked at code comments knows that. Much like their dramatic brethren, they may have told the truth sometime in the past, but not today. We need more information so we run more tests. These are now characterization tests: they are now helping us ascertain the state of the system, rather than make sure something is right. or wrong.

The end

Finally, there’s the right prognosis. Good or sometimes bad, or too late. Either the project is salvable (everybody expels a sigh of relief) or doomed (a gloom in the room).

So why does everybody says life is not exactly like on TV?

What The 5th Agile Principle Really Means

The Agile Manifesto has 4 principles. In Agile 2008, Uncle Bob Martin in his keynote suggested a 5th principle:

Craftsmanship over Execution

(Yes, I’m 3 years late for the party, but bear with me. This came to me as I’m preparing to my NDC talk).

All principles were written by technical people who emphasized communication and value for the customer. The fifth is different.  It’s intended for a subset of the group the rest of the principles aim for. Craftsmanship is for the coders.

Makes sense, doesn’t it? But wait…

I’ve been talking about how developers and business people don’t speak the same language. Miscommunication begets mistrust.

By declaring we’re the craftsmen (read: and you’re not!), we’re widening the gap that we’re supposed to bridge together for the customer. And  by separating ourselves apart from the rest of the agile team, once again we’re not considered team players.

And there’s less trust.

And we put ourselves at risk.

Ok, now it’s your turn – tell me I’m wrong.

My “Expert Unit Testing Tips” Presentation

This is the presentation I gave today at the “QA and Development in Agile” conference (It’s a bit more detailed than what the people in the room saw).

This wasn’t a technical presentation, just an overview to the newly initiated to unit testing – third of the room wrote unit tests, the rest didn’t. And if you weren’t there: I talked about unit tests and TDD, how to make the most of them, and about Typemock tools for unit testing and bug prevention (our new tool Armadillo).

Slides are nice, but you’re missing on the experience.

Would you like hear me present? Write me a comment!

Presenting at QA and Development in Agile 2011

I’ll be presenting this Thursday, May 19th, in Sela’s “QA and Development in Agile”, in Ramat Gan.

The presentation is called “Expert tips: Unit testing tips for the agile developer” (It’s going to be in Hebrew). Also appearing in the conference are Typemock alumni Lior Friedman and Dror Helper.

I’m going to hang around all day there, so if you’re there (and if you’re in Israel, why wouldn’t you be?) look me up!

PS: I’m going with Adi Beker, so expect some more awkward pictures (probably of me) on the @typemock twitter.

The Truth About Agile Adoption

It’s spring time for agile. The birds are singing and main stream companies are adopting scrum. Everyone knows that agile brings us out of the unsuccessful projects of past to a shining successful future.

Unless, you go back to the report that started it all - the CHAOS report.

The CHAOS report is used universally as metric ton of project success. It looks at how projects meet their spec, cost and duration plan. And looking back 17 years since its inception it has taught us that news are bad for projects, with only 32% meet their plan, and the rest fail in someway, 24% are considered complete failure.

That was the proof we needed to call for change. Agile was the cure.

And agile has flourished. According to Dr Dobbs and Forrester Research survey (info here is taken from Mike Griffiths post) in 2009, many companies took on agile in some form.

Put together, the formal agile methods with iterative  development goes up to 56%. Which means the majority of companies have adopted agile. And the results?

 

Well, it looks that things haven’t changed much according to the CHAOS reports! Sure there’s a slight improvement, but not the sharp ramp we wanted to see here.

But let’s read the fine print. Let’s look at what the CHAOS numbers really mean. To quote Mike:

The CHAOS reports definition of successful is not “functionality within +/- 20% of budget or schedule” as you might think. Instead they calculate a project’s success measure by counting the number of projects that have an initial forecast larger than the actual for cost and time, and one that’s smaller for functionality. This is divided by the total number of projects to calculate the success rates. Standish Group defines its success measure as a measure of estimation accuracy of cost, time, and functionality.

Ahh,  so our measuring stick is a bit crooked. Also, last time I checked, success is decided by customer satisfaction, not the Standish group.

What’s the truth?

Things are improving, and agile is becoming mainstream, slowly. The proof is out there – in conferences, on Twitter, and hopefully around you too. However, following blindly a flag (or at least not reading the fine print) is a good recipe for one day waking up disillusioned.

Get your own numbers. Measure your own goals and define your success. Letting someone else do it for you (or not doing this at all, for that matter) is just plain dumb.

What do you think about the state of agile? What’s the real truth?

Related Posts Plugin for WordPress, Blogger...
Twitter Delicious Facebook Digg Stumbleupon More