Clarity

If you hire someone to build stuff, then you want to let them do their job properly, otherwise, it is not a surprise when the things they build do not work correctly. It would be expected.

Computer Programmers write code. Before they start this work they should at least put together a low-level design, as it tends to save a lot of time during the coding and testing parts.

A low-level design comes from the mid-level design, which fits into the higher-level designs. Designs set the constraints and keep everything organized. They match the solution to the problem. If you don’t have any designs, what you will get is just a pile of disconnect stuff, that rather obviously won’t work very well.

For small, or even medium-sized projects, some programmers can visualize the design in their heads and go from there. It’s not a super common attribute, but if they can “see” the work, they can build it. This might confuse people, who falsely assume that there was ‘no design’, but its lack of documentation does not indicate that it was never done.

Programmers tend to focus on the workflow from low-level designs, coding, testing, bug fixing, and some involvement in deployment. But that is a subset of what needs to happen. So, the border category of Software Developers spans the full range, all of the way out from conception, analysis, high-level designs, politics, funding, management, process, methodology, to any operational issues and getting feedback on the suitability or stability of the system.

If the project is medium or larger, you need at least one experienced software developer to lead the way. They have to have deep experience (10+ years) with all 5 stages (analysis, design, coding, testing, deployment) and be able to make sure that the end-to-end flow of the work is reasonable.

Even though a Software Developer gets involved in operational issues, they are not an operations person. They are there to pick up requirements, test suitability, figure out the technical competencies, diagnose serious problems, etc. But they are not 24/7 support. They are not system administrators, database administrators, support people, helpdesk, or operators. They build stuff, it is up to someone else to ‘operate it’.

When you ‘run’ a system, you need a bunch of people to monitor it and keep it working properly. Newer technologies like ‘the cloud’ don’t change that, not even a little bit. If you have a bunch of systems that need to be up 24/7, you need a bunch of support specialists who ensure that things are up 24/7. Nothing can get away from that fundamental issue. If the system is low quality, they need to know a lot more in order to keep it running, making them more expensive and harder to train properly. So better quality in the code is generally a good way to reduce operational costs.

Failing to understand what the different roles should be doing will end up blurring the tasks and responsibilities, which ultimately results in very low-quality development work. A programmer that is burnt out from late-night operational issues, is not someone who should be crafting code the next day, or even that week. Burn the ‘builders’ and what they build going forward will be worse, not better. To build good stuff you need to concentrate rather deeply. Noise, stress, rushing, anger, etc. are all counter-productive.

There is a minimum threshold of quality that enables the software to have enough value to be able to pay for itself. If the work falls below that level, it becomes a cost sink. That is, it is wasting more money than it is enabling. It is possible for the initial quality to be good, but over time for it to degrade to a negative status, and eventually, it all turns red, So, you can see ‘profitable’ projects that while still sitting on a lot of initial value, have reserved their direction towards becoming cost sinks. It happens all of the time.

If the project started out successfully but then turned into an epic disaster, it is not an easy choice to shelf it and start over again. The risks of a new project are significantly higher than the risks of reorganizing and refactoring. That is, the least risky way of getting large and huge systems is to grow them. But to grow them you have to have the foresight and keep control over the technical debt. If they become disorganized messes, the work will grind to a halt. These are nebulous concepts that are fundamentally difficult to understand, which is why you need an experienced Software Developer at the helm.