There's a lot of lessons that can be learned from it, but I think that this one is perhaps the most important and also the most overlooked: to address a problem, you don't actually need to be able to solve it yet.

When talking about problems with accessibility, security, user safety, and so on, programmers have a tendency to dismiss these problems because they can't see an immediate solution, or for some reason they're unable or too difficult to implement it right now. So it's marked as 'not planned', and everybody moves on.

But let's consider the way traffic engineering has changed over the past decades in the Netherlands. It was originally just as much of an unsafe, car-infested sewer as many other cities; if you look at pictures from the 1960s or 1970s, it looks almost indistinguishable from anywhere else.

But then at some point, someone decided "we *want* to solve these problems". They couldn't actually fix anything yet; transportation infrastructure is expensive and hard to change or replace. But it didn't matter; they decided that solving these problems was now a *priority*. This is where the idea of Sustainable Safety started, which you may have heard mentioned before.

That decision changed the framing. Now, instead of automatically doing the same thing as before, every new decision and design was evaluated against the new design objectives, and improvements were made opportunistically where it was possible. If a road had to be renovated anyway, hey, why not replace it with something better?

There was never some grand cohesive plan of the exact changes to be made in every place, there was never some big total redesign of the road network. There wasn't even a concrete idea of when the process would be 'complete'; there was only a decision to prioritize safety going forward, and a decade-long process of asking "how can we get a little bit closer to that goal?" every time a design choice needed to be made.

And this is exactly what you can - and should! - do in software development, when dealing with the difficult, seemingly intractable problems, especially those that management will not set aside time or resources for.

All you need to do is accept the problem as one that needs solving, and ask yourself throughout the design process, whenever you make a design choice: "how can we get a little closer to this goal, is there low-hanging fruit here?"