On Paradigms

On Paradigms

Software engineering is a social craft. I think this concept is foreign to many, so I’ll dwell on it for a moment.

Software engineering is not programming, nor is it computer science. Programming is, reductively, the creation of code; computer science is, reductively, the study (and theory) surrounding that code. Software engineering benefits from and involves these things, but the core of it is using software to solve problems.

Solving problems is inherently social. Even if you are working on an isolated issue that only affects you and will only ever effect you, any solution you build still has, at minimum, the collaborator of your future self. The management, the “lifecycle” of the solution, is the primary concern of the software engineer. Is it understandable, is it repeatable, is it maintainable, is it correct (and can you prove it?), is it executable - these are all the sorts of questions that an engineer must ponder and answer, and you’ll note that they’re all relative. If the social context around your solution is comprised only of non-technical people who don’t, won’t, and can’t read or understand you code, the nature of “is it understandable?” changes. If you’re working with a group of overworked geniuses who have great knowledge and advanced tooling and minimal time, the answer to “is it maintainable?” takes a particular form it wouldn’t if you were working with a group of mere mortals with lots of time.

I’ve written before about how communication is the primary function of a software engineer, and have established a(n incomplete) list of generally good guidelines around it. The above begs a meta question equally worthy of discussion:

What social paradigms harmoniously allow and encourage good software engineering?

This is something I’m still trying to crystallize an answer to.

Pain

I was discussing this idea with a colleague and they had a compelling suggestion, which I’ve since shopped around to several others and it’s rung true to all of us: pain. More specifically, “who feels the pain of not doing software engineering (or doing it poorly)?”

Imagine an engineer is on-call, and an incident occurs. Good software engineering can reduce the likelihood of incidents, but is unlikely to eliminate them entirely, so let us assume this is not wholly avoidable. In most cases, the engineer will feel the pain of not doing software engineering (well). Are there useful error messages or logs to investigate? Can the relevant code be understood? Have changes to the codebase been properly logged and documented (perhaps with a well-scoped PR with a meaningful description)? Can the engineer find the bug at all, and if they can, are they able to reproduce it? Can they do that expediently?

The answer to all these questions is hopefully “yes!”, but the key thing to note here is that this poor on-call engineer is incentivized to make that the answer, because they’re the ones who suffer if it’s not.

On-call is not the only way to experience this, of course. There are pains associated with PR reviews; with implementation; with the performance of the team and the cache of the engineering organization as a whole and the health of the business, if in a business context.

This is also a helpful, if not always actionable, way of framing other organizations that engineering must operate with. Product managers can feel the (once-removed) pain of poor or non-existant software engineering as features come out slower and with lower quality than they otherwise might. Quality assurance, so often awkwardly in-the-eng-org-but-also-not, certainly feel the pain of buggy releases, or changes that are difficult to test (manually or automatically). Sales feels the pain of an unreliable product that demos poorly and lacks competitive functionality.

I find this framing helpful because it also highlights a key difference between these orgs - only software engineers can do software engineering well. Sales might feel the pain of poor software engineering, but they cannot make it better. By the same token, if software engineers never feel these pains, they have no incentive to avoid them. To wit, one of our paradigms is:

Software engineers must feel the pain of poor (or non-existant) software engineering.

This is also a useful mechanism for understanding orgs where engineering is a waning power. To continue picking on Sales, if they never feel (or perhaps more accurately, never understand) this pain and they are the dominant force in the broader collective, then they will push for the outputs they care about (more features, reliable demos) and will pressure engineering to deliver these at cost of otheroutputs. So to expand on our paradigm above, we must also add:

Decision making organizations must understand the pain of poor (or non-existant) software engineering.

Sales need not experience an unreliable product to know that it will demo poorly, and if they can understand how slipshod engineering work in a given situation will leed to that outcome, they too are incentivised to encourage and promote good software engineering.

None of this is particularly groundbreaking, but I find it helpful as a way of framing and evaluating the problem in practice.