Regardless of the technology, most general-purpose software is easy.
- There’s a set of requirements.
- Someone implements said requirements.
- Code gets tested, problems are fixed, and code issues are resolved.
- Code is promoted to production.
- New requirements come in, and the process repeats.
- Dependencies change. Someone tests them and releases a new version.
Like anything else critical to the business, software needs to be monitored. Every aspect from the list above can be streamlined and/or automated.
- Open Source software and libraries: use the global brain. Someone already had that problem.
Be a good citizen, open source your code, and contribute back wherever possible, please. - Unit and integration tests: clicking through test scenarios does not scale.
Someone is paid to sit there and click through tests. One person can click through one scenario at a time. Automate that process. Have thousands of virtual persons doing it at a whim. - CI/CD: automated upgrades and production promotion: once the code is automatically tested, there’s nothing preventing automatic production code release. There are exceptions to this rule, of course. YMMV.
- Automatic monitoring: released software adheres to specific KPIs. Any non-conformity results in automatic rollback or notification to the operation team.
- Rollbacks can be automated.
- Backups can be automated.
- Backup restore can be automated, but human supervision is advised.
The software does not live in isolation. Software is constrained by technical, societal, and political issues.
Technical ones usually do not go beyond some head-scratching. Maybe there’s VPN, or maybe there’s a need for a proxy. A wire format has to be converted to another one. Maybe there’s very little compute available, or storage can be done only via some third-party object storage. We can generalize: in software, there are no unsolvable technical issues.
Societal and political problems are tougher to solve because human interaction is involved, often centered around emotional matters.
But two things do not scale for sure:
- Meetings: once someone attends a meeting, they’re bound to commit their full attention. They cannot do anything else at that time. Is the meeting necessary?
- Custom code: if the global brain does not have the answer, someone has to write the code. A pair of hands can only crank out so many lines per day. Make it count and avoid politics. A brain of a developer is focused on solving a problem. Any interruption derails the thought process. The longer the interruption, the more difficult it is to get the thought process back on track. Political interruptions cause uncertainty, and the focus shifts to a different track, the one the developer is often not accustomed to dealing with.
Solutions:
- Prefer asynchronous communication with continuous documentation. Good knowledge is documented, not passed on by word.
- Passing on knowledge by word promotes cliques.
- Cliques lead to office politics.
- If the meeting must be:
- Announce before what’s the expected outcome. What is the meeting about?
- Document the outcome: take minutes.
- Allow healthy deviation from the beaten path but identify side-tracks quickly, and move them offline.
- Remove political obstacles. Developers are paid to write code, not to participate in the power struggle theatre.