Don't Write More Code

As strange as it may seem we aren't in the software production business, we are in the solution delivery business.

What I mean by this is we shouldn't measure our effectiveness by the amount of code we produce but by the number of solutions we deliver.

We should actually consider code a necessary evil in delivering these solutions with it counting more as a liability than an asset.

Costs of Production

If viewed as a commodity code is pretty costly to produce, developers are highly skilled well paid people and good code can take time to engineer.

If we define an implementation that requires a lot of code to be written we are increasing our costs and putting our deadlines at risk.

We need to make sure that developers time is spent on writing the code that provides the features we really need, not re-inventing the wheel or falling into the not invented here trap.

The essence of this approach is re-use, whether this be utilising 3rd party code that does what you need or by recognising when you write code of your own that what you're writing will be the answer to a similar problem in the future, effectively reducing the time to provide the solution the next time round.

Whenever you find one of these re-use potentials your reducing your costs and making it more likely that you'll hit your deadline. 

Production Defects

Whenever we write software we are usually writing defects at the same time.

While I wouldn't suggest that its impossible to produce a small piece of code riddled with bugs or a large piece of perfectly bug free code, there is undoubtedly a relationship between the amount of code we write and the number of defects we create.

This is not only a problem because we don't want to ship bugs but also we create a vicious circle of even more developer time, which we've already established as expensive, being spent on fixing the issues. 

Re-use once again is our friend, by re-using code, especially well tested code, we can ensure that we build our software on strong well understood and proven foundations, reducing the amount of new code that is likely to cause defects.

Maintenance Not Guaranteed

Code can rot if not maintained, this can be because of constant change to deliver new features, hacks or patches being applied or not being kept updated with changes elsewhere.

The more code you have the more rot your going to see, and once again this brings us back to the time and cost of having to maintain and fix that code.

Yet again re-use can help us, by ensuring we are using the same solution whenever we encounter the same problem we reduce the amount of code that needs to be maintained.

If we discover a problem in a library or package we can fix it once and feel the benefit in every other code base without expending any more effort or cost.

Its very easy to fall into a trap of engaging in engineering software for purely technical reasons.

We are enthusiastic about what we do and gain pleasure from doing it, but our industry is not about production lines. We aren't employed because of our ability to produce code, we are employed because of our skill in utilising software to achieve business outcomes.

There doesn't have to be a relationship between the amount of code we produce and the number of outcomes we achieve.

Think of software engineering as a constant process of refinement rather than as a means to bring more code into the world.