Managing Software

1.0 Why Do We Need Software?

We have software to help us automate tasks that are part of a workflow. Software is the tool that is used both internally and externally to provide a service. Internally that service aims to automate tasks, externally that software provides a service to the client.

1.1 Internal Software

Software is required within a company to automate complex workflows that would otherwise require several employees to execute. Or a long time to execute. It is generally used as a tool to manage and improve operational efficiency.

1.2 External Software

External software exists because there is a need for it. More and more online businesses have ever inreasing complex workflows which can no longer be done by a small team. Hence, there are opportunities for software to automate and replace these complex workflows. Since this software is client facing it is generally paid for either by currency or through user engagement.

2.0 What Makes Good Software?

When we are writing our tools we have 3 basic questions we should always ask ourselves.

• Is it easy to use?
• Is it easy to understand?
• If this was your business would you be doing it the same way?

It is not enough for software to accomplish the task, it needs be accomplished well. When I say it needs to be accomplished well I mean it should be easy to use. I normally ask myself “what would Google do?” “is this done to the same standard?” even if you don't have the same budget doesn't mean you shouldn't hold yourself to the same standards.

We should be able to take anyone off the street who has never used this product, give them basic instructions and they should be able to use it. We need to aim to create good products, not hard to use scripts. You could have written the best software in the world but if it’s impossible to use you may as well have never written it.

This is one quote that I always think of when i’m creating anything. Its from Marcus Aurelius’ meditations. This quote is a reminder to always keep first principles in mind when you are creating something. You have to be honest and objective with yourself with regards to what you have created. There are different aspects of writing good software:

• First Principles: You should always ask yourself: What am I really trying to accomplish? Is this thing I have created actually accomplishing it? Am I really fixing the problem? Is this too manual? Can I automate more of it?
• Visual (UI/UX): Is this GUI as easy to use as it can be? Do I even need a GUI? Can we embed this task in an existing workflow? Is this overcomplicated? Is this style over substance?
• Data: Everytime we hardcode something in a GUI or a script is an opportunity for creating a datamodel that can be formalised and stored in a database or even provided as a service.
• Scale The tools that you should be writing should also be built with scale in mind. One day that script could be running across 100+ servers ...
• Monitoring Good software is built with monitoring in mind from the start. Your software, your script will fali at some point. An assumption that you have made will be false and you need to account for that from the beginning. Making good decisions here will save you countless hours down the line as long as you respect the workflow that is being automted/optimised.

3.0 What Tools Do We Need to Create Software?

The tools you should use should be whatever your are comfortable with. Ideally these tools should be something that the wider industry is using so the skills that you are learning about using the tool is providing you with a skill that outlasts your employment.

This gives both you and the employee an incentive to learn the tool and buy in from the entire team means that if one person has found some productivity improvements the rest of the team can benefit from them. The tools that I tend to use are:

• GUI (UI/UX): Penpot
• IDE: VS Code
• Architecture: Diagrams.net
• Database: DBeaver / DataGrip

4.0 When is Good Software Complete?

How long is a piece of string?

Writing good software is never finished. Things will change; it is inevitable. Be it a business process or an imported 3rd party library. The key is to have written software that is resilient to these changes in the way it is written and the ease of which the software you have written can evolve.

5.0 How Should We Maintain Good Software?

From a product owner perspective we need to make sure software is used often and ask for feedback on the application often. Workflows change and the original workflow that the software was designed for may not be optimal anymore. You need to ensure that the application evolves with the business needs.

One way that you can increase your confidence in making these changes is ensuring that critical aspects of your software has been thoroughly unit tested.

6.0 How Should We Keep Making Good Software?

You need to keep caring. Caring about the software. Caring about the people that are going to be interacting with it.

6.1 Caring about Software

The times where I have seen software decay or software become unusable is when the people in charge of it don't care about it anymore or have lost interest in it. Quite often it happens to software which was inherited by a team. They stop respecting the boundries and rules of the data structures that were setup in the first place. They start to make changes which weaken the pillars that the application was built on.

6.2 Caring about People

Another reason is that the technology/framework that it was written in is dead e.g. Smalltalk (kapital) or languages that aren't used in the wider community (slang, hack, athena python). Most people don't want to invest time and energy into something that they can't use outside the office. Unless you think you are going to stay at that company forever. Core skills such as data structures, separation of logic are transferable but these custom languages/frameworks carry little to no weight in the job market.

Companies these days are in the mindset that if our employees have useful skills they will leave. You should leave any company that has this type of skill extortion. If your employees continue to learn and grow they will stay because they can see that they are making progress.

6.3 Caring About Software Engineering

You also need to make sure the development experience for writing features in the application is as simple as possible. The key main areas that need to be automated to make devleopment easier is the following:

• Identity Management your employees shouldn't have to remember 5+ passwords so either embed an effective sign on strategy or pay for a good password manager with access control and shared passwords.
• Source Control pick one type either Git or a CVS type repo and ensure that the automated build/deploy/test tools exist and are easy to implement.
• Automated Deployment Once a user has made a change, there should be a facility to deploy that code to DEV/PROD on approval with no extra steps.
• Automated Testing Code should be tested automatically before commit with little to no environment issues. Nobody wants to make changes to their local environment just to get your code to work.
• Virtualisation VDI's are not fit for purpose for normal software engineering practises. A better solution is to use Yubikey or other hard tokens on commit and pull and let users have root access on their laptops. VDI's just tell your employees that you don't trust them. The cost savings are also immaterial, rather than pay £X per laptop you are paying £X per year for a desktop experience that is nowhere near as good as having your own hardware.

This is essentially the bare minimum that you need to care about, beyond this you can include having a thorough onboarding process, centralised and up to date documentation and service discovery tools e.g. Spotify Backstage. Once these are established you need to maintain tight feedback loops to ensure that your tooling never decays.

6.4 Caring About Change

Business processes will inevitably change and workflows will have to adapt to remain relevant. Hence, it important to include in regluar reviews with the employees and be one step ahead of the workflow change. At this point it will be important to revisit the Workflow Properties outlined in Section 4.1 to ensure that we maintain workflow integrity.

7.0 Conclusion

Writing software is hard, writing good software is even harder. You need to have an awareness of several extremely difficult skillsets and near mastery of all of them to ensure that the product that is shipped is fit for purpose. Not only that we need to ensure that the product we have can evolve with changes in the business.