Faith-Based Software Development

How do you know that? Are you sure? Why?

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.

2 thoughts on “Faith-Based Software Development”

  1. Speaking from personal experience, I think the biggest disincentives to checking and testing are

    1
    I have a lot invested in this already and I really don’t want to test this bit and find it doesn’t work.

    and

    2
    Testing is hard and I have to keep my brain alert because there is no pre-ordained route to good testing – and I am tired and I want an easy life.

  2. Good ones!

    Related to #1 is “I’ve already burned the hours I was supposed to devote to this, and if it cycles back through the tracking system as a new defect a week from now it won’t affect my timeliness on this task.”

    A good solution to #2 is having a good unit test framework in place. Then a lot of the test creation is done for you via JUnit-like wrappers and such. It’s even better if you’re doing TDD, in which writing the test code is very tightly integrated with defining what the method is going to do, which you have to do anyway, right? Shouldn’t take any extra time at all.

    One I’m hearing about lately (#3) is “I’m senior here, the code has always been done my way, and I’ll lose clout if that changes.” I wonder what the motivation is for cultivating that clout though.

Leave a Reply

Your email address will not be published. Required fields are marked *