Happy Path Programming

There are two kinds of sloppiness in software engineering that really annoys me.  Both are variations over the same theme:  just programming the "happy path", the scenarios where everything works and everything is okay, and just skipping the rest.

The first has to do with misapplication of the current fad in startups "lean".  Everyone is "lean" now and everyone is doing "minimum viable" this and that.  Well, that is all well and good when you need to validate stuff.  You should go at it as heartlessly minimalist as a busload of Bauhaus architects when you need to validate something.

But it is idiocy when it comes to stuff that doesn't need validation.  For instance, when Toyota build a new car they do not put cardboard brakes on the car because they need to validate a bunch of stuff and they think they can skimp on brakes.  They put real brakes in.  Because they know the car is going to need brakes and they know how to build brakes(*).

The other comes from people trying to sell you some technology.  A framework, a language, whatever.  They'll show you how you program the happy path and point to how easy that was. ...And then mostly omit gnarly real-world stuff like error handling and the fact that someone might come along to maintain the code or perhaps even integrate it into something else.  Quite possibly without the benefit of developers that are as enthusiastic about whatever it was you got tricked into buying.

Turns out that when you add all the stuff you actually have to think about back in, it isn't so easy after all.  Because the cognitive workload lies in actually understanding the problem you are solving.

(*) Actually, they just take the brakes off the shelf and bolt them onto the car.  Because they have this brilliant concept of components that can be re-used by composition on different cars.  But you get the idea.

No comments:

Post a Comment