Responsible Software Engineering (by the Software Engineers)

There is a lot said nowadays about ownership: "product ownership", "own your code", etc. I am going to define ownership as control and responsibility – in this instance, control over and responsibility for the code-base (both generally and specifically).

The salient point here is that control must sit with the same person/people as
responsibility. This assertion is based on the pragmatic logic that someone cannot take responsibility of something that they do not control and one cannot exert control over something that one has not taken responsibility for.

Let us use an ever recurring example from software development: developers are considered responsible for delivering (working, up to standard, quality) code. This is so simply because they, and in the overwhelming majority of cases – they alone, have the skill and ability to create and fix computer code.

What often happens, however, is that management takes control over the code delivery (this usually involves obsessing over a date). Yet management cannot take responsibility for writing the code because they do not have the skill to so.

Management knows what the business needs, not the technical detail of implementing it.

Ultimately, the software engineers, and they alone, are actually in control of what code is written and delivered. (Hopefully it is delivered to or, even better, with, QA.)

What most often happens – in this scenario where control and responsibility are allocated to separate parties – is that quality drops. Management is unable to gauge this drop in quality and it's future effects (because it's not in their skill-set). The managers then blame (set responsibility on) the developers who
throw up their hands and say "we told you so".

The solution is for management to give control over the coding to the software engineers and for software engineers to take ownership of their work. An effective and easy way to start this to have the engineers themselves construct the plan,  it'll give them ownership of the implementation and give the plan credibility in their eyes.

I'll discuss making the plan flexible and the interrelationships between scope, time, resources and quality in another post. My next post will (probably) be on Business Vision v Technical Detail. Views expressed are my own.