Developer Manifesto – You Are an Artisan, Not an Engineer

If I had wrote that, it would have been about how it led to the development of the Cesarean section operation. In the US, and many other places, the prevalence is much higher than the medical need. When there is no medical need for a C-section, there really isn't any benefit over the risks to the mother and child. Also--and this will probably sound quite hand-wavy or too woo-woo for most of HN's demographic (I assume)--there is great emotional benefit from a baby passing through the vagina.

In the UK at least, from my experience there, the term 'engineer' is applied to many more people than I would have expected. E.g. "an engineer is coming to look at my boiler". In the US the term 'technician' seems more common/appropriate.

> throw something away and do it again.

This jumped out at me too. This is such a HUGE fallacy. If what you have written is core to or is the product you're selling, you can't just rewrite it! Software evolves over time, and it can become difficult to replace it when it gains features and bug fixes for random edge conditions.

Properly replacing existing software requires having a consistent API against which you are developing and can test to make sure that it continues to work. And then having the ability to potentially dark launch new software next to old to see that it works properly. Even doing all of that, replacement projects often fail, why? Simply because most organizations can't afford to have a team that is not contributing to the bottom line of delivering features to customers.

Doing a replacement project should never be started without a significant amount of thought and attention. Software always takes longer to develop than you think, I even underestimate "Hello World!" most of the time.

Aerospace software engineer here. :-)

I feel perfectly content to deem my work as "engineering". I can understand why someone quickly whipping up a small web application (which is not to imply that all web applications are quickly whipped up, nor that all web applications are small) might reasonably feel that their work is not engineering.

So since I've also done quick little web applications, what do I think the difference is?

The aerospace work includes precise operational requirements. It includes formal verification tests which demonstrate that the requirements are met. Code is reviewed; documents are reviewed; reviews are reviewed (not joking, though typically only a sampling subset). Code is subject to formal coding standards; code repositories are subject to formal standards; tools for testing software are subject for formal standards (and documented/reviewed/etc. in their own right). Software that goes onto aircraft is tested in simulations; tested in limited on-ground hardware scenarios; tested in extensive on-ground hardware scenarios; tested on board flying aircraft. The entire process (and the following of process) is reviewed. The end product is signed off on, and, for example, in the case of U.S. commercial aerospace, certified by FAA representatives.

Sounds nothing at all like developing web applications!

Or does it?

A consumer-facing startup web application might have little or no requirements. Testing may be ad hoc. Nothing is reviewed. Coding standards don't exist. Does the software seem to do what is intended? Ship it!

But what about web applications for banking? I've never worked in banking, but I suspect the requirements are fairly robust. (And if in fact they are not, they easily could be.) I suspect that tests are comprehensives, traced back to the requirements. (And if in fact they are not, they easily could be.) I suspect that the software goes through several rounds of testing, that code is reviewed, that coding standards are adhered to. Maybe not to the same level as aerospace, but probably pretty solid.

So what?

Is financial software engineered? I would imagine so. Maybe not as strictly as aerospace -- or maybe stricter! I honestly don't know. But I can easily imagine comparable scenarios.

So if we can engineer financial software, can we not engineer productivity software? We sure could! How about social media software? You bet! Even games? Why not?

I think that all software could be engineered. But in fact it probably shouldn't be. If you want to make a change on software on an aircraft, it might be five minutes editing code in Emacs, surrounded by a year of paperwork and process. That'd be ridiculous for an iPhone game. It'd probably be excessive for a financial application, but maybe some measure of that would be appropriate.

Perhaps there is (or should be) a spectrum of software engineering. At one end, we take extreme measures to ensure quality and process, because (literally) lives depend on it. At the other end, we can hack out whatever we want and it doesn't matter. Most software lies somewhere in between. Maybe some of it should consider moving more toward one end or the other. :-)

[Incidentally, it's common to repeat the phrase, "never roll your own cryptography software". I think it would be totally fair to say "never roll your own flight control software" too. But the people actually writing flight control software aren't necessarily top-tier 0.000000001% brilliant developers. They are, though, surrounded by sufficient process and review that their work is nearly guaranteed to be solid by the time it takes to the air. We could probably do something similar with cryptography software, if there were a model in place (and, I reckon, funding in place) for all of the surrounding infrastructure to engineer it properly.]