GASP? … or not.

Doctors have a rule for sterilization, or “Always Wash Your Hands.” Simple things that can be done to improve the outcome of every single project.

At the recent, GLSEC keynote, Bob Martin asked us “We were all doctors, and a hospital administrator called a meeting, telling us that we were spending too much time washing out hands – would we stop doing that?”

Of course not. Medical professionals know the risks involve in skipping that step, and simply won’t take it.

Likewise, Accountants have a concepts of “Generally Acceptable Account Principles“, or GAAP.

I started writing this blog entry intending to find some “Generally Acceptable Software Principles” (GASP). After all, if accountants and doctors can do it, why not us software guys?

And, in fact, I have a few. My colleague and friend Andy Lester does some speaking and consulting, and his immediate refrain is “Bug Tracking, Version Control, and Daily Backups.” That is to say, if your software organization doesn’t have these three things, trying to do anything else for “process improvement” is a waste of your time. Get Bug Tracking, Version Control, and Daily backups first.

I recall that Steve McConnell had a few talks on this subject, so I googled around, and found Software Development’s Low Hanging Fruit and the Ten Most Important Ideas in Software Engineering.

Now, I like Steve McConnell. I’ve read his books, we have corresponded a bit, and I’ve quoted him quite a bit in my writing. For the most part, I like what he has to say. But his low-hanging fruit is nothing like what I would recommend, and his “ten most important ideas” reiterates the classic cost-of-bug-fix curve.

That might be true for some organizations, but it isn’t true for all.

I got thinking about GASP because on one email thread this week, we discussed the possibility of having Test Driven Development go mainstream, and I wrote this:

I don’t know if TDD will ever go mainstream. My prediction is that we will continue to have a large group of people who are doing a ‘good enough’ job of development that don’t read books or go to conferences. Those people will become managers, and if they hire a new grad who knows TDD, > 80% of those new grads will just follow the prescribed, crappy process instead of looking for a unit test framework for Ada.

One of the great things about software development is that if you have an idea, you can go into your garage and build something cool and sell it. Then you grow, have to maintain legacy code, and process becomes important. All over the world we have companies on a great continuum, between life-critical software and video games for a PDA.

It would seem to me that to require software engineers to be licensed, to require, perhaps, an advanced degree (think law or medicine) and a board of examiners might increase our process, but it would create barriers to entry that would stop a lot of really smart 16-year-olds.

I was once a really smart 16-year old without so much as a high school diploma.

It seems to me that the best thing we can do as an industry, is to not outsource our discernment about what practices are “best” or “right” or “professional”, but instead keep that responsibility to ourselves – and live with the consequences of carrying that responsibility. Then we can judge our practitioners by the output they produce.

What do you think?

One comment on “GASP? … or not.

  1. I like your concluding paragraph a lot.

    The question of whether TDD will ever go mainstream is interesting. If no other variables change, your prediction is probably right. At our company we’ve been doing a lot of recruiting of university seniors lately. We’ve been surprised to find that none – literally none – of their teachers has ever mentioned the importance of any form of testing whatsoever, let alone test-driven development. If and when TDD becomes taught in schools, we may begin to see it become a more mainstream practice.

    You’re right that it’s a personal professional choice. I had lunch with a colleague recently who complained that the manager he’s currently working for explicitly told the team to stop writing unit tests because he wanted them to spend their time developing code. He works in a TDD fashion, and was frustrated by this decree.

    I reminded him that TDD is a development technique, not a testing technique. If TDD is the way he develops code, then he’s not violating the decree by continuing to develop code in that way. Since TDD enables us to develop clean code rapidly, the manager will have no reason to complain about the results.

    Unfortunately, the word “test” in TDD leads to misunderstanding about what the technique really is. I wonder if that may be another reason why TDD has not already become a mainstream practice. BDD and development-by-example seem to be easier for people to grok, just because the terminology doesn’t suggest “testing.”

Leave a Reply

Your email address will not be published.