Hacker News Reader

I think there is agreement, or at least slowly developing consensus, that some software should be "engineered" and some should just be "developed". But there is not yet really a structure (that I have seen) for declaring which thing your project is doing and setting up your practices accordingly. One reason this is tricky is that many (most?) projects start in the should-be-developed category and only transition to the should-be-engineered category later after they become mission critical in some way. The answer is often to build an "engineered" version as soon as you can figure out you need it. But then that's even more expensive than doing it that way to start, and it's also a really tough call to make because everybody knows rewrites are a bad idea. It's a tough bind for all but the most obvious cases. And then because those obvious cases are fairly few and far between, the best practices and the experiences of most of the workforce are skewed toward software that merely needs to be "developed".

To make this concrete: a couple times now in my career I've embarked on projects where setting up any level of formal verification at the beginning would have clearly been overkill, but where a few years later I really wished I had it for certain important pieces. And now since formal verification is so uncommon in my experience, I would have to play a lot of catch up to do it, even for a project that is clearly important enough for it even from the beginning. I think this is a pretty widespread experience.

A key difference between physical engineering and software engineering is that the economics of over-engineering to improve safety margins are wildly different. For physical engineering, the costs of substantially decreasing failure risk (e.g. via increasing strength, different materials, more complex design, etc) is approximately linear. For software engineering, that cost is something closer to quadratic or worse.

This is intrinsic to the differing nature of the problems. Verifying the safety of a bridge design is computationally trivial, verifying the safety of non-trivial software is NP-Hard. Safety is so inexpensive to add in physical engineering designs that we invest a lot of effort removing incidental unnecessary safety.

> verifying the safety of non-trivial software is NP-Hard.

While true, this depends very much on the design (or lack thereof) of the software system. Many of our software systems are more complex than necessary because they weren't designed or the designs weren't considered carefully enough. When the software is allowed to grow and accumulate masses of code virtually unchecked, it becomes computationally intractable to continue to verify the system.

Much of the software involved in aircraft, specifically, can be reduced to very simple designs and implementations where the necessary safety analysis is feasible.

The present complexity is often in the accumulation of legacy defects and corrections (fixing the right problem in the wrong place) or trying to fix hardware problems with software. I'm not 100% pro-rewrite, but many avionics software groups (that I've encountered) refuse any rewrites on certification grounds but end up with something unbearably complex as a result (simulating hardware databuses from the 1980s in software on a 1 GHz processor when the system was initially targetting a 16 MHz processor).

Try to solve an aerospace problem with this "simple" approach. No, you don't get to add strength willy-nilly, or just swap materials on a hunch. You're working with safety factors which sometimes are less than 1 (come back for references), and those physical properties of materials are notoriously stubborn to changes. You know, some Richard Feynman once quipped "nature can't be fooled, dammit" - that extends to "water boils at 273.16K full stop (standard conditions), no, you're not going to change that".

Yes, you can often do more complex design. Sometimes though it costs you centuries to choose a good combination of existing physical properties (architecture), and sometimes it's "just" decades (Gravity Probe B). Wanna propose similar approach to software? :)

safety factor less than 1? you're planning that the thing will break early?

Liquid fuel rocket engines sometimes could be planned to work under the plastic deformation stresses, not elastic stresses. Given that their life-cycle is measured in seconds, such an approach - which brings some admirable weight savings - could produce results.

Writing software is not engineering - engineering is building the same thing over and over again and you slowly learn how to do it the right way. There are incremental improvements along the way - stronger lighter materials, better tools, etc. But the folks who built the Roman aqueducts could get up to speed pretty quickly on the Golden Gate Bridge.

The principles of flight don't change. The fundamentals of building a skyscraper or a bridge don't change. There are hundreds of years of learning behind those things that are still relevant today.

Building airplanes and bridges and skyscrapers is not hard at all. People do it all the time with a high success rate. The hardest part is scraping up the capital and managing the logistics. I'm sure none of that knowledge is required to get any kind of engineering certification.

If you redesigned every bridge and airplane from scratch, from first principles, you would have a tremendous failure rate no matter how many certifications you held. That's what software is - every project is a brand new thing that has never been done before - there isn't 200 years of learning to fall back on.

One of the worst things that could happen to the software industry is for bureaucrats and other people who know nothing about software to really believe it is an engineering discipline and try and regulate it as such. We'll all be forced to do a fantastic amount of busy work to meet arbitrary and archaic "engineering standards", and the software will actually decline in quality. You'll be fined $50,000 if you use tabs rather than spaces, or don't use yoda compares in your C. But as long as you are using spaces and yoda compares you won't be liable for a failure. Stuff basically like that.

Maybe when we have 200 years of experience writing software, rather than 50 or so, we can start to think about formalizing it as an engineering job.

>That's what software is - every project is a brand new thing that has never been done before - there isn't 200 years of learning to fall back on.

Sorry but this is just gatekeeping bullshit. Most apps being built today by companies with the budget to build them are TODO apps, report apps, storefronts, big data mungers, CRMs, etc. They all just have different business requirements and domain specific knowledge. To think that every software project can't be categorized is ridiculous.

I honestly don't know what gatekeeping means in this context.

> all just have different business requirements and domain specific knowledge

Yeah - that's what I said. You realize that's where all the complexity is, right?

>I honestly don't know what gatekeeping means in this context.

you're trying to create a barrier to standardization. You don't want to codify successful patterns to keep your job coveted.

>Yeah - that's what I said. You realize that's where all the complexity is, right?

That's not what you said.

You're being extremely uncharitable.

Look, business processes are different at every single company. Especially between companies doing the exact same thing. Which means that the software ostensibly doing the exact same thing at each of these companies is going to vary dramatically. Because the software at a company aligns to the business processes of that company. This is the true heart of Conway's law: "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations."

And there is no fixing this. It's baked directly into the axioms. If every company in a domain ran exactly the same way, there would be no such thing as a competitive advantage.

> you're trying to create a barrier to standardization. You don't want to codify successful patterns to keep your job coveted.

Ugh. I use as many libraries and services as possible so I can focus on writing code when no standard tools exist. That will keep me busy every day forever. If you think I'm out there sabotaging standardization efforts you're delusional. I wouldn't even know how to do that. Slash tires at a W3C convention or something?

Yeah, and a lot of that software sucks because the companies who pay for it to be developed want the cheapest possible thing that just about works and not some ultra-engineered unkillable concrete bunker of an app that costs them 50x more. That was the entire point of the agile revolution - get rid of waterfall methods inherited from classical physical engineering and switch to constant iteration and shipping, with fixes to not-quite-right work being done whilst workers are in the building. Software engineering became less like regular engineering because that's what the customers wanted, and who's to say they were wrong?

The firmware in all the electronic gizmos in your life aren't running "just apps". Much of it is poorly developed shoot from the hip code that is riddled with bugs. Some of it is running in cars and planes that manage to kill people because of hubris.

And some of it is developed under standards like ISO 26262, or IEC 61508. You would be amazed at what goes into your steering, braking, airbag, and stability control systems.

You think that's most of what's being developed today? Life critical firmware?

> it's that (in theory) the sheer volume of man-hours spent pouring over every minute detail of them, incorporating lessons learned from every failure that's ever happened in the field, amount to a very very high success rate

and this is what company executives need to understand. Given the fleeting nature of software and the speed in which one can write working code (not strictly correct or bug-free, but something that apparently works) people are convinced that software development should be cheap -- or cheaper than say airplane design. Software design is thus seen as cost not investment and those flaws in specifying and writing correct core is then shown in not treated edge cases, sometimes catastrofically

The problem isn't that executives don't understand, it's that they don't care. Capitalism's incentives do not encourage the practice that's best for society. The only industries where care is taken are the ones that have been regulated to be as such. And then there are cases like Boeing, where that regulatory structure decayed and the safety practices decayed in tandem.

This reminds me of one of the first conversations I had with my manager when I started my current job as a software engineer.

I used to work at a large financial company who had an intensely rigorous approach to verifying it's software in both manual and automated ways, as well as a much more careful approach to writing code to begin with.

When I started here (a much smaller startup delivering marketing software for small business clients), I brought up that I was concerned about going to somewhere with a less comprehensive testing pipeline in place, to which I was told:

"It's not particularly important to be able to find bugs before they're released, it's more important to optimize the deployment speed so that we can release the fixes quickly"

Sounded crazy to me at the time, but I later realized it's really all about what your industry is optimizing for, and what would cost you more money.

> it's really all about what your industry is optimizing for, and what would cost you more money

Sure, those were not critical systems, they could be patched with minimal hasse to clients. However you can't really predict catastrophe costs. It could range from minor usability issues to hard to trace calculation errors that could jeopardise the whole production operation. If the company doesn't work work with prototypes it should invest heavily in test coverage, integration test and delivery pipelines

It's a very elaborate way of saying "writing correct software is hard". You know what's also hard to do correctly? Designing airplanes. Building skyscrapers... the sheer volume of man-hours spent pouring over every minute detail of them, incorporating lessons learned from every failure that's ever happened in the field, amount to a very very high success rate.

It's not only hard, but the cost/benefit (or the large penalties of catastrophic failure) works out so that it's worth it to go to that amount of effort. The same amount of effort doesn't go into building a backyard garden shed. I'll grant that we've gotten to the point where the cost/benefit analysis demands that we go to that amount of effort in critical situations.

You're ignoring cost. Want to build software like we (were supposed to) build 737s -- to always work? Watch your costs go up by (rough guess) 10-100x.

We've generally made a decisive choice for functionality and cost over bugs.

Which isn't to say that I don't agree that there are areas: self-driving cars, airplanes (required here), human diagnostic software (already required here), etc that should have much tougher standards. But across the board ... I don't think people are willing to pay for that.

Perhaps one of the reasons for this is that software doesn't allow humans any way of leveraging our evolved "danger detectors".

It's hard to make a safe building, and it's hard to make safe software. The difference is it's (often) incredibly obvious that a building isn't safe the moment you step into it. In software it's sometimes pretty much impossible to tell the difference between a stone temple and a house of cards.

It is incredibly obvious to people with the knowledge and skills. They can look at code and just by glancing at it can have a gut reaction that triggers red flags. Sometimes it can even be an emotional disgust. It's just not common knowledge. We as a community need to do a better job at transferring this knowledge.

Proper strong typing, not just the weak typing that is more common, provides these "danger detectors". It makes it a compile error. Compiler errors make things immediately obvious.

Type systems are very rich and most statically typed languages that are commonly used now can barely count as type systems when compared against what we know from mathematics and computer science. They merely describe the data format (or not in the case of nullable) and not acceptable inputs. They don't allow types for scenarios like requiring a function that exhibits these behaviors but not these other ones.

Pattern matching in combination with strong typing requires code that handles all possible inputs or you get a compiler error.

Dependent typing requires inputs to be within certain tolerances (not just adhering to a data format).

Type systems can also make certain race conditions impossible to create.

That's not really true. Much of what makes a modern construct safe is extremely unintuitive; material science being a big example. Some modern buildings are even designed to look precarious on purpose, for aesthetic effect, despite being very sound.

> The difference is it's (often) incredibly obvious that a building isn't safe the moment you step into it.

This is just not true. If anything, our "danger detectors" probably give off an equal amount of false positives and false negatives when judging the structural integrity of objects we're unfamiliar with. And the same holds true for code bases, which is exactly why it makes sense to hold software to a similar standard as physical engineering.