Saturday, July 2, 2016

The case for SLOW programming

Every other posting about software these days is about 'go fast' or 'quick delivery' etc. Agile everywhere; Agile every time!

But, there's a case for SLOW!

How about when you're asked to code up some morality; when you're asked to code the decisions which are philosophical, steeped in moral decisions, and perhaps are quite personal?

This project issue is embedded in this essay about coding the autonomous vehicle.

Let's say you're doing the coding for some decision making the car's control must address:
You’re driving through an intersection and three people step into the road; the only way to avoid hitting them is to steer into a wall, possibly causing serious injury to yourself.

Would you sacrifice yourself?

Now change the equation: There are four people in the road and you have two family members in the back seat.

Do you still steer into the wall?

Would it matter if one of the pedestrians was a baby? If one of them was old or very attractive
Should we just put this scenario into some story cards?
 "As an autonomous vehicle I want to ... when ..., or else ....",
Code it up, and call it DONE? Then, release it to production as soon as the functionality is certified?

Or, do we do a BDUF* (gasp!), and thoughtfully go through the morality tree. In other words, take it SLOW!

And, is this a case of the wicked problem where there are only virtuous circles, endlessly conflicting needs, and no satisfactory point of entry or exit?

Did I mention -- I don't have the answers to any of this. But I hope Google and others do.

*BDUF: Big design up front, the thing we are supposed to rid ourselves of

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
Read my contribution to the Flashblog