On Abstraction [video] | Hacker News Reader

On Abstraction [video]

youtube.com

61 pointstosh22 comments

In the bridge analogy he implies that software engineering cannot be more like civil engineering due to changing requirements. He stretches the common analogy of building bridges by suggesting it's normal to add a car-wash to the middle of the bridge before you've finished developing it. This is the norm in software development so there's no way we can engineer a software solution with the same rigour as other, proper, engineering disciplines!

I do believe software engineering can be more like civil engineering and that there are organizations around the world which will license capital-P engineers in software. Just because requirements change does not mean we cannot write mathematically precise and robust models and definitions of systems. It also doesn't mean we cannot, a priori, build software that is as robust to operating conditions as a bridge.

What we're doing as an industry when we run software in production without clearly known limits is simply taking risk. We could know what the tolerable limits are of a particular server are or precisely define the probability that a given change will reach quorum within a particular bound of time. However for a good number of projects we're comfortable accepting that our customers will discover those omissions for us and no one will get hurt.

However if you're writing software to control robotics that help people walk or air-flight control software to safely land multi-million dollar jets you're probably going to take more precautions to design and test your software and create detailed, precise specifications.

Update: To take the bridge analogy in a different direction: it's more common in the software industry to build two bridges: the one most people use but could fall down at any time or the bridge that costs a significant amount more but there will be a small team of developers waiting to help you get up if it does.

update update: The point is you can write sound models of your abstractions and prove properties about them with sufficient tooling. Much the same way that a blueprint is an abstraction of the bridge that is built, we have ways of writing blueprints of software systems.

I think software engineering cannot be more like civil engineering because software is the result of the decision making process. In civil engineering, the blueprint is the result of the decision making process and the bulk of time and cost is building from that blueprint.

You cannot compare the process of building a bridge to building software; you could compare the process of constructing the blueprint with building software. And I think the scale of complexity of most software far exceeds the complexity of most blueprints.

No software is creatively fathomed out of nothing. Opinionated frameworks abound, pre-ordaining the little manouevres needed to wire them up properly, and solving familiar problems with established patterns. If these have all been decided beforehand, even if only by convention, then what are they but blueprints?

What difference there is works in software's favour: there's a frothy top layer of most projects where developers can indulge their whims/hone their abilities and approaches. But it's not the whole.

Physical items are built the same way; everything is built from smaller components many of which are farmed out to other providers. When you have a blueprint for a bridge you don't also plan the forging of the bolts.

The parts you're talking about (in either software or bridges) are important but aren't where the design effort goes. Everything interesting in every project is in that frothy top layer.

They aren't blueprints, they're foundations and components if we're going to stick to this analogy.

Blueprints are specifications and design documents. Most software lacks these.

Specifications and design documents are merely estimations. If you've made every single decision possible, you've written the software.

If you have blueprints for a bridge and get two different companies to build it, you'll get the same bridge both times. The differences, if any, would be minor.

If you give specifications and design documents to two software teams you could get radically different products that look nothing alike and it's entirely possible that neither one of them will satisfy the clients needs.

If they don't meet the clients needs then they were the wrong spec and design document.

Honest question: without a specification, how do you verify your software?

There is plenty of software that is driven entirely by specification. Inputs come in and outputs go out. And you validate that with a test suite, etc.

But even more software is designed not for machine-machine communication but for machine-human interaction. And humans are notoriously bad at knowing what they want and need. In some cases, the existence of software so fundamentally changes the nature of work that humans don't even have the frame of reference necessary to provide full specifications. Yet the software still has to be written, do it's job, and be accepted. I'm not sure I have an answer to your question but somehow I still get the job done.

Given a formal model or proof of a system and the two teams will either succeed or fail.

Give them a specification in prose and they will have a little too much wiggle room. Such specifications are useful to a degree but I look at them like sketches on a napkin.

If you use a more formal method of mathematics as your specification then you can be more precise about the invariants that matter and model your system more faithfully. And with a good proof assistant or model checker the computer can even help you catch flaws in your design that you would never have been able to think of on your own.

It's true that the source code is a proof of something. It often helps to know whether you've built the right thing. And that it does what you think it does.

Given a sufficient model or proof of the system and you don't need the teams at all -- they can be automated away.

Getting your model right is as hard, if not harder, than getting the software right in the first place. The problem hasn't changed you've just added more layers (and more cost) in the hopes that doing it twice, differently, eliminates most of the problems.

For some trivial small problems writing a model in TLA+ or Lean is definitely more costly than just writing the software even if you get a few things wrong. It'd be like commissioning a blueprint for your shed in the backyard. For those sorts of tasks it is sufficient to just write a few tests and call it a day.

However for more complex services that are trying to manage several clusters of resources amongst tens of thousands of tenants or more there are invariably going to be errors. The kinds of errors you see might require a particular series of events to change your state in 53 steps to hit it... but if you're servicing > 1M requests in a minute that ends up being frequent enough to be bothersome.

Even more so if you're working on a memory controller in a new hardware platform that is expected to ship in a few million units. It'd be nice to know that you have strong evidence that your system is correct.

And developing models is hard but so is thinking. Nobody said it was easy. But one shouldn't say that we can't engineer robust software systems. It's just patently false.

The other thing is, when you build physical things the way you do things is constrained by, well, physics.

Nobody goes and builds an MVP Golden Gate Bridge and then just shores it up in production or piles crap on top of it, and anybody with a shred of sense builds a solid foundation before they go and put up a skyscraper. In software it's too easy to get things in to working state that are hanging by a thread.

Surprise you're programming a machine that is governed by physics!

Want to render that scene on that PS4 console over there at 60 fps? Well that disc drive can only read bytes so fast and you have to update the physics simulation before all those effects are applied... 60 times per second. Physics.

There is enough useful stuff in first-order and temporal logic for dealing with all of the challenges that specifying systems with the given properties and level of confidence that blueprints give us.

And that's why we need good tools for reasoning about and specifying systems.

Amazon and Microsoft seem to trust TLA+ for designing some of the most complex systems in production today. I'm pretty sure they wouldn't have pulled it off without formal methods (Amazon released a paper about their use of TLA+ and MS has mentioned it's role in the development of Cosmos).

Software systems can be specified using precise, robust blueprints. Those blueprints are expressed in math and I believe from my own experience that they are immensely useful.

I think building software is more like building a whole city for millions of people in one go. The bridge has a very simple goal, to cross from one place to another. Also you would need to speed up time a lot for it to be comparable. Imagine if technological change was so fast that by the time you finished building the bridge there were flying cars everywhere.

Blueprints are not that important when you need to build something that needs to adapt. Take for example olimpic stadiums that no one uses, they might have good blueprints and all the regulations but who cares now they are still useless. On the other hand take the exampole of haussman buildings in paris they are still being used and proved very adaptable.

I guess it might have something to do with nassim taleb's concept of antifragility. Software is very rapidly proved to be fragile because it operates in a context where there are a lot of black swans. On the contrary bridges operate on another time scale wher it might not be so obvious how fragile they are but given the correct scale you would have bridge builders facing the same problems as software developers.

[edit] Also you need to take into account the crazy fact that you build software based on some facts but the software you build changes those facts, so now you need to change the software that will change the facts so on and so forth.

Zach Tellman's book (http://elementsofclojure.com/) is also mentioned in the talk and worth reading. I'd argue it is even worth reading if you don't use Clojure.

There is a free example chapter on naming.

I thought this was a good talk, but it felt like an overview of chapter 2 of SICP. Not a bad thing, but if this interests you give SICP a read as well.

In the first ten minutes of the talk, the SICP definition (which is taken from the Hoare paper) is examined and discarded as too limited.

https://en.wikipedia.org/wiki/Naming_and_Necessity seems to be an overview of the "fruits of 100 years of analytical philosophy" mentioned as inspirational for the naming chapter.

This is pretty fascinating, and, truth be told, I am very much not into Clojure or anything related (quite the opposite, really). I wish there was more thinking and reasoning about the basics of abstraction, naming, etc.

There wasn't a single line of Clojure in that hour-long talk, I don't get your point. Do consume the content before you comment on it.

I thought the part where he talked about over-engineering being a symptom of a lack of understanding of the assumptions was an interesting way to look at the problem.

Reply on news.ycombinator.com