Computer Programming vs Software Engineering

This talk by Russ Cox, one of the co-creators of the Go programming language at Google, is an awesome walkthrough of the rationale behind testing and some practical approaches to doing it a software engineering context.

An interesting idea that got me thinking is the distinction between programming and software engineering.

Programming is getting a software to work.

Software engineering, according to Cox, is “what happens to programming when you add time and other programmers”.

Let's unpack this a bit: By time, it refers to the expectation that a well-engineered software system is expected to work and keep working for a long time, long after the programming is done.

Toward this purpose, the code written must not only achieve the desired goal (as with programming), but also be understandable, extensible and maintainable because it will most likely have to be understood, troubleshooted and worked on by other people.

For me, it also means that while in programming there's joy to be derived in refining the code itself to achieve some abstract sense of beauty and perfection, this is a non-goal in software engineering.

In engineering, code is only the tool to achieve some end-goal and to serve some purpose to the business. We, programmers, just happen to enjoy it.

As they say: “there are no perfect solutions, only trade-offs”.

On one hand, a paper on programming will attempt to generalize concepts and find truths which are universally valid or valid within a set of constrains.

On the other hand, a piece of software which is deployed to millions of users will contain a plethora of compromises and logic which looks puzzling out of context, but which was added to tackle some issue seen in practice.

Of course, there's some balance. Too many workarounds in an engineering context often leads to unintelligible and brittle code, which could be solved by some more fundamental rearrangement or abstraction.