Faith-Based Software Development

Yesterday, while discussing a particularly difficult team-energy kind of problem, something led me to identify their methodology as “faith-based.” Everyone laughed, and they immediately got my point. Faith in a process is really no way to run a development shop.

If what you want is to feel good about your process, by all means have faith in it. If you prefer oustanding (or even decent) results, develop your ability to observe and adapt. And have faith in that.

One of those unexpected life lessons

When I was all of twenty years old, my best friend used to interrupt quite a few of my (many) sweeping statements by asking, “Are you sure?” And then “Why?” I’m not sure that questioning technique was intended to change forever the way I think about things, but it did.

Scientifically, we have to go and check things to find out what is true. So when a lead explains a lack of unit tests by saying they take too long, I have to ask, “Are you sure?” and then “Why?” Sometimes I can combine the questions as, “What makes you say that?”

The same goes for establishing goals and objectives. Once it’s been decided what your organization needs to be successful, which are really values issues in the first place, the next thing is to examine specific goals. Architect this application. Support that infrastructure. “Does the FOO application help us hit benchmarks? Are we sure? Why?”

So much for thinking strategically.

Most of my work is far closer to the line. At that level, the day-to-day production work of making software, you need to know what works (so far) and what doesn’t work (yet). For you.

You know the aphorism that goes “if you can’t measure it, you can’t manage it”? I think that’s wrong; there are obviously a lot of important things that get managed, and need to be, but don’t come with handy statistics. Do the best you can with the subjective stuff, whether it’s by instituting a pain scale (e.g., 1 for barely any pain, 10 for theworst pain you can imagine) or by ordinary observation (e.g., “Sharon says she’s less stressed than a month ago”).

Success comes from continuous improvement, a constant revising of your strategies and tactics. So a lot of what I do is asking, “Is that working for you? Are you sure? Why?”

The need for continuous observation and correction is constant. Have faith in that. The resulting strategies, tactics, tools, and techniques are (or should be) ephemeral. They are your servants, not your guides.

That’s why it’s so hard

When teammates or managers get dug into what’s obviously (to you) an unproductive process, consider what’s in it for them. Is it really as blunt as job security? Is there a more important motivation like belief in a value system, respect for a mentor, fear of being caught out? Control and insecurity go together a lot. Or do they seriously just not know any better?

Do you?

What kind of practices and ideas do you have faith in? How have you dealt with others who do not share the same kind of faith? How has your software development faith changed over the years? I’m looking forward to the comments on this.