Archive for April, 2006

Over 1000 defects?

Guy Kawasaki has a funny and true to life list of the top ten lies engineers tell. But, almost as an asside he says:

Generally speaking, if the largest number of documented bugs doesn’t ever exceed 1,000, it means that the company isn’t tracking bugs carefully.

Which I think is crazy. Well, perhaps if you are Apple, or Adobe, or Microsoft, there’s some truth to this. But, my experience is that if you let the bug list get that high, on any 10 person project, you have a serious problem. Rather than spending time documenting bugs, spend time fixing them.

Your client isn’t paying you to track bugs, they are paying you to write software that works!
If you do test driven development you will fix lots of bugs at the moment of writing them. My experience is that the lower the time between when the bug is written and when it is found, the less time and energy are required to fix it, partly because you know where to look, and partly because the problem is still fresh in your memory.
If you are a manager, prioritize fixing bugs above creating new functionality.

If your boss walks in the door and says, we need feature X for customer Y, and it is your number one priority starting now, take a deep breath. And say, “That sounds great, but we have some important issues we need to take care of first in order to make sure that customers X, Y, Z, and A are all happy wth the quality of the software we deliver.” If you are afraid to do this, then get a better contact list and start lookign for other work, because standing up and taking responsibility to get bugs fixed is your job. Having other options in case your boss tosses you out on your ass, might make it easier to find the courage to do your job.
It may take courage to say no to new features until the curent defect problems are resolved, but you are the only one who can do it.

The more bugs you have, the harder they are to fix.

Ultimately, if your team isn’t fixing bugs faster than you create them, you face the very real possibility that your software project will be flooded. Eventually, your project could end up taking on new bugs faster than you can triage the existing problems, and you’ll sink just as sure as the Titanic once it started taking on water faster than the bilge pumps could bail it out.
“Quality is free,” doesn’t mean that it’s cheep, or that you can get quality without sustained effort. It just means that creating quality work, from the ground up — every single time, will actually save you money when you no longer have to pay for all the inspections, returns, and other costs that come from poor quality.
The same is true in Software Development. Ron Jeffries seems always asks “Why do you have so many bugs that you need a bug tracker? What’s wrong with your process?”

Toyota, when faced with defects, asks “how is our process broken?” and “How do we fix it so we don’t get this problem again.”

You’d be surprised what you can do when you treat bugs as quality problems that shouldn’t exist. You’ll definitely write more tests, and at first you’ll spend a lot more time fixing bugs. But if you manage to get it right, everything else in your whole system will go faster and more smoothly. And eventually, you’ll think the idea of tracking 1000 defects is insane too.

TurboGears at the Ann Arbor Java Users Group — May 2nd

AAJUG logoI just got back from doing a TurboGears talk at Penguicon, and now I have been asked to do the TurboGears dog and pony show at the Ann Arbor Java Users Group. The talk is May 2nd, I’ll do the standard intro to TurboGears bit, but I’ll try to throw in a bit of and extra evaluation of several of the “next generation MVC” frameworks and how they compare to Struts.

Of course, I know more about TurboGears than any of the other frameworks, but I’ve taught classes, and done a few talks on Rails too. So, I think it should at the very least be interesting.

I don’t have the room number but, I’ll be presenting somewhere at Washtenaw Community College. I’ll post an update when I have the room and time details.

Living with Yesterday’s Best

Sometimes I am better than I was yesterday. Usually that’s a good thin, but it can be a problem for me because I start feeling bad about yesterday’s work — I fell that I should have done it better yesterday.

Sometimes I am worse than I was yesterday, either because I am tired, or I’m distracted, or I just have a headache. And that can be a problem — after all I should be getting better — not worse.

These feelings of guilt are very much related to the problem I discussed in “Always doing your best considered harmful?”

I feel like I ought to always do my best. The problem is that when your best changes day by day, hour by hour, you’ll never be doing your best by some definition of “your best”.

The other day in my annual review we were talking about how I helped someone in my team with managing his tasks and priorities. This individual had definitely turned a corner and the same people who had criticized him a few months earlier were now singing his praises. But I wasn’t as happy about this as I should have been — after all I should have helped him turn this corner months or years earlier — it turned out to be so easy. All I had to do was re-define his job requirements in terms that motivated him. He is a real people person and doing everyday project work was hard for him, but when the work was framed by who he would be helping and how it would make their life better he was happy, even excited to do it. All I had to do was tell him “your job is to keep X, Y and Z happy by doing A, B and C,” and he clicked into gear. Why didn’t I do this a couple of years ago?

Because I didn’t know what needed to happen yet. I’m working to learn that there is no shame in getting better — even though that means that I used to be worse.

Will Ruby and Rails save my IT Department?

My client is not an IT person and he knows nothing about programming…. I started sharing [Ruby on Rails] with him…. About ten minutes into my presentation he interrupted me and said, “So, this could save my IT department, couldn’t it?”

This is from Dave Thomas’ blog, where he is quoting an e-mail where Eric Knapp just gushes about the possibilities that Rails brings to the table. It seems nice enough, and everybody is well intentioned. But, I must admit I have my doubts. First of all, it sounds like a thousand non-technical managers getting sold on some new technology without taking time to understand the real life benefits and risks.

But it goes further than that, I doubt that Rails will ever save anybody’s IT department.

Can it make IT departments more productive? Absolutely. But when a department is broken that’s not usually just because they have bad tools, it’s because the staff either aren’t interested in finding better tools, or they are crippled by organizational red tape, or they are too afraid to tell management that the current tools suck.

“Whatever they say the problem is, it’s always a people problem.”
– Gerald Weinberg

Rails, TurboGears, Django, Plone, and even Zope and EJB 3 all offer the hope of more productive web development. Better tools are important. But a growing, healthy, team can discover, evaluate and when necessary the fit between these new tools and their current projects is the critical factor in long term success.

Rails may appear to be the world saving framework today. But it is not the end of the road, people are hard at work inventing better tools (for example, SQLAlchemy is poised to become a far better Dynamic Language based ORM than ActiveRecord), and if your team can’t evaluate new tools as they come they will end up stuck when Ruby on Rails is surpassed by other tools.

If you Rails is the end of the line, rather than just a remarkable jump forward –which will itself be left behind by new tools in the future — you’ve been fooled by the hype machine.

By the way, since I’ve noticed a few people in the Rails/Ruby community have a thin skin, this whole post should in no way be understood anti-rails. The problem is not the technology it is the marketing and the the uncontrolled hype which doesn’t admit the limitations of the technology.

But, in the same way that Rails won’t save your IT Department, TurboGears will not save you, nor will Zope, or EJB 3.

You have to save yourselves by becoming a place where software teams have the freedom to learn, grow and experiment with new tools.

TurboGears Documentation Sprint!

Humantech will be hosting another TurboGears sprint on April 29th from 10 am to 5 pm eastern time.

Be there!  Or join us online via IRC chat and participate virtually.

Together we can make a huge difference in the documentation, and push TurboGears that much closer to 1.0.

For more information join the TurboGears Sprint making list: