August 6, 2012

...Learn TDD with Codemanship

Back To Basics #11 - To Learn, We Must Be Open To Change

This is the eleventh of ten posts covering basic hype-free principles for software developers. Yes, I said "eleventh of ten".

If there's one thing we can be certain of in this crazy, mixed up world, it's that we can be certain of nothing.

In previous posts, I've alluded often to change, and how important it is in software development.

This final post - putting aside my feeble joke - seeks to reify change to a first-order component of successful software development. It deserves its own principle.

As software development is a learning process, and since we learn by incorporating feedback in an iterative sort of fashion, it stands to reason that our software must remain open to the necessary changes this feedback demands.

If we're not able to accomodate change, then we're unable to learn, and therefore less likely to succeed at solving the customer's problems.

But, although we call it "SOFTware" (and, admittedly it is easier to change than things made out of, say, concrete) changes to software don't come at no cost.

In fact, changing software can be quite expensive. More expensive than writing it in the first place, if we're not careful.

What happens when software is too expensive to change? Well, what happens when anything becomes too expensive? That's right - nobody's willing to pay for it. Except fools and madmen, of course.

Software becomes too expensive to change when the cost of changing it outweighs the benefits of making those changes.

A surprisingly large number of software products out there have reached this sorry point. All over the world, there are businesses who rely on software they can't afford to change, and therefore can't change the way their business works.

When a business can't change the way they work, they struggle to adapt to changing circumstances, and become less competitive.

The same goes for the software we use in our daily lives. We may see many improvements that could be made that would add a lot of value, and we may have come to rely on the version of the software we're using. But if the people who make that software are unable to incorporate our feedback, we end up stuck with a duff product, and they end up stuck with a duff business.

Meanwhile, competitors can take those same lessons and come up with a much better product. There are thousands of new businesses out there ready, willing and able to learn from your mistakes.

To accomodate change in our software, we need to minimise those factors that can be barriers to change.

Some of these factors have already been touched upon in previous principles. For example, if we strive to keep our software simple and readable, that can make a big difference. It will make our code easier to understand, and understanding code makes up the lion's share of the work in changing it, as studies have revealed.

If we automate our repeated tests, this can also make a big difference. One of the risks of making a change to a piece of working software is that we might break it. The earlier we can find out if we've broken the software, the cheaper it might be to fix it.

Automating builds and release/deployment of software can also help us to accomodate change. Teams that frequently integrate their individual work find that they minimise the impact of integration problems. And teams that can quickly and cheaply release or deploy their software (and safely undo that deployment if something goes wrong) are in a much better position to release software updates more frequently, so they can learn more and learn faster.

There are other important factors in our ability to accomodate change, but I'm going to end by considering two more.

As well as making our code simple and easy to understand, we also need to be vigilant for duplication and dependencies in our code.

Duplicate code has a nasty tendency to duplicate the effort required to make changes to the common logic in that duplicated code. We also risk duplicating errors in the code.

We must also be careful to minimise the "ripple effect" when we make changes in our software. Ask any experienced developer, and they'll be able to tell you about times when they made what they thought would be a tiny change to one part of the software, but found that small change broke several other parts that were depending on it. And when they fixed those dependent parts, they broke even more parts of the software that were in turn depending on them. And so on.

When the dependencies in our software aren't carefully managed, we risk the equivalent of "forest fires" spreading throughout it. A seemingly small change can end up turning into a major piece of work, costing far more than that change is worth to our customer.

Finally, in order to accommodate change, we must be open to change. The way we work, the way we communicate with each other, the way we plan what we do, all has to make change - and therefore learning - easier.

Too many professional software developers have a fear of change, and too many teams organise themselves around the principle of avoiding it if they can.

For example, many teams do everything humanly possible to avoid customer or end user feedback. They can become very defensive when someone points out a flaw in their software or makes suggestions for improvements. This is often because they fear they cannot act on that feedback, so they employ the coping mechanism of hiding, or getting angry with the person offering the feedback.

Many teams employ complex, bureaucratic procedures for "change managgement" (which is software-speak for "discouraging change") which can only be designed to put customers off asking for new things.

The language of software development has evolved to be anti-change: commonly used terms like "code freeze" and "scope creep" are aimed at encouraging a culture where change is bad, and no change is good.

When we approach software development as a learning process, and accept that much of the real value in what we create will come from feedback and not from what we originally planned, then we must not just tolerate or allow change, but actively embrace it.

Posted 5 years, 7 months ago on August 6, 2012