Should? No. Wish.

Some Twitter chatter and a moment of not knowing what I wanted to code this morning has led me to think about what people should do.

A number of my Colleagues in Agile, as enthusiastic as I am about the power and value of the simple programming techniques that I speak of here, small steps, support by tests, and continual refactoring to improve the code, well, these colleagues sometimes seem to be saying that other folks “out there” should be doing these practices, and if they’re not, well, it probably explains the long bug lists they probably have, and the long delays before anything gets done, and pretty much anything that’s going wrong, including the dust in their corners and the scurvy that seems to have taken over the tomato plants in the garden.

Now, I read what these folks write, and honestly, they’re not really saying anything quite so direct and insulting, but you can definitely tell that they think people who don’t use the ideas we share are missing out on some good results. And it frustrates them, because they know how good these ideas are, and how much pain they can remove from a programmer’s life, and how much joy they can provide, and they are frustrated to see people suffering more than they need to.

Sometimes people see these tweets, and they get surprisingly upset, as if my colleagues had called them out personally, and said “Hey Alex, the reason you have twenty times more bugs in your spawny code is that you don’t practice these simple techniques that any fool would be practicing and besides your mother dresses you funny”. These people get upset and often nasty, taking offense where none was offered. We can discuss elsewhere¹ what causes people to take offense when it wasn’t offered, but I want to say here what I think about these practices and how “you” “should” behave.

I have six decades between my first program and today, and I have consciously tried almost every² software development approach that has appeared. Working in small steps, supported by tests, and refactoring early and often is the best way that I know to program. What do I mean by best? The things that I show you here, give me the following valuable things:

• I am lost and confused far less often;
• I make continual progress;
• I get a sense of continual improvement in the program;
• I can deliver new features every day or so, keeping The Man happy;
• I rarely inject defects that reach the outside world;
• I am rarely tense or nervous during programming;
• I rarely experience that loss of orientation that calls for a reset;
• I can talk to people and write articles at the same time as programming;
• I enjoy seeing tests work, and code get nicer;
• I am really having fun.

Is it perfect? No. Frequent readers here have seen me release bugs in my little programs, and have seen me identify the cause, quite often the lack of a test that I could have done but didn’t. Readers have seen me lose the thread and need to revert, usually because it had been a half hour or hour or more since I last had a green bar and could commit the code.

I’m not perfect, and no practices in the hands of an imperfect person can be perfect. But what I know, from long years of working this way, after years of working in other ways, is that this way of working is far and away more enjoyable and more productive than any other approach I’ve learned.

So should you be doing these practices? Well, I freely grant that I think skill in these areas will make your programming life better, I have no claim to what you should do. I wish that people would see these ideas, find them interesting, try them, gain skill with them, and find ways to fit them into their work in a way that improves their lives. I wish that. I do not say that they should.

What people do is up to them. Imposing a “should” on people is, to me, the start of oppression.

But I wish people would try these things, because I think their lives would be just a bit better.

I don’t think they should: I wish they would.