My career as a software developer has been fairly unusual as I spent about six years as an IT manager for two companies. It was not an intentional change of focus but happened unexpectedly after taking a job as an Oracle database developer. That job changed shape immediately, in the form of a job offer for a job I was not interviewed for. It was a big undertaking for both my employer and for myself, but in the process it exposed me to many challenges that most developers have no experience of.
It is my belief that my current software development skills have been enriched as a result. I also believe that other software developers would be able to act more effectively with a little investigation around the edges of their own areas of expertise. In this brief article, I hope to encourage you, my readers, to swim a little further out to sea. I hope you find it useful and can make your way back against the tide!
Testing for correctness
Have you heard of integration testing? This is where you test how the software that you and your team have developed interacts with the surrounding eco-system. Perhaps you already do a lot of integration testing. If not, I certainly encourage you to do it, at least in some form. However, if you are performing integration testing without a consideration of the wider eco-system— networks, storage devices, processing platform, operating system options and configuration, drivers, patch level, etc.—then you are leaving open a multitude of untested areas in your product. Whether or not these risks are considered acceptable or not to your business is a matter of judgement, but wouldn’t it be nice to at least smoke test these? Or alternatively, wouldn’t it be nice to know and understand how the test environment is constrained similarly and differently from the real world environment? Not being able to answer these questions means that you won’t be able to tell the IT manager engaged in deploying your software the answers to his justifiable and reasonable questions.
Product ownership and leadership
One of the major failings in the modern world (I have seen it in governments, commercial businesses, charities, churches and social groups) is abdication of ownership. More generally, I see this as a failing in leadership, but that is a discussion that is probably best conducted in another post. A failure in ownership means, typically, that important things are left undone, because there is no one that considers it to be their job to ensure that it is done. Note how I have phrased the last sentence, “to ensure that it is done”. It is not always the case that the person taking ownership of an activity is the same person responsible for performing the activity. Nevertheless, not having someone who is willing, able and empowered to take ownership of the activity defeats success almost every time. We need more people to take ownership of the things for which they have been deemed responsible, or at least been given responsibility for.
In relation to software development, ownership leads to a need for a product team to understand the eco-system in which their product will be deployed. I mean, to really understand. I mean to understand to the degree necessary to be able to describe the entirety of the product’s function for which they are responsible.
This means that they should know how to deploy it. They should know how it has been tested. They should know how it has been designed. Importantly, they must, they absolutely must, be able to describe how to use it, in all of its uses, to their user community. Finally, they must be able to maintain it and support it.
I cannot see that any of this is possible without the team taking a high level of ownership of the entire product for which they are responsible.
Owning a deployment platform
If this level of ownership is to be achieved, then software developers must aim for at least level 3 of the Capability Maturity Model: Defined—a standard business process. In other words, they must be able to correctly deliver an equivalent configuration based on a repeatable and well-described process. This is not possible without understanding the configuration of the operating system, and equally of related functional areas.
For an example, a very simple but typical two tier web application deployed on self-hosted hardware would need:
- Two physical machines
- One, single disk system with minimal RAM, CPU and memory
- One, RAID-1 operating system and database log disk; one, RAID-5 array for all other data files
- One network switch
- Two operating system installations
- One web server installation
- One database server installation
- One database schema deployment
- One web application deployment
- Two firewall configurations
- Two security configurations
The complexity quickly builds up. Is there a SAN? Is there a central network authentication system? What protocols are being used? UDP? TCP? IPsec? LDAP? Kerberos? SOAP? XMLA?
Taking ownership of a product means taking ownership of the aspects of this that matter to the product’s correct function. At the very least, it means knowing how to deploy the software and how to configure each part of the overall solution for correct behaviour. It does not mean understanding everything; it just means understanding enough.
We need software developers to recognise that they develop products deployed into eco-systems, not products acting in isolation (well, at least that is true for most of us). Therefore, it is critically important that we take responsibility and ownership for what we know and for what we require to be controlled. We need to improve the quality of software development in the industry. Would it not help if we at least could describe how the software we were responsible for creating works?