Stop the Line. I mean, stop the car!

Some problems or failures of development do not manifest until the product goes live (the servers go up, the car hits the streets, etc). The Stop The Line mentality of manufacturing and the Just In Time (JIT) practices are great at rolling out product, but when things happen quickly, there is not a lot of time for forethought and there is very little time for testing outside unit testing or TDD. What other kind of testing is there? Human testing… user error testing… real life, this thing is now rolling along and we got it out fast but damn, I am not sure that was the best way to do it testing. Analysis is lacking. Isn’t a tenent of Agile that you cannot know everything up front? Does that mean that we say, “oh well, we will figure it out when we get there?” Classically it does – with a little bit of “keep it in our sights” thrown in. However, there are cases where it should not and this latest fiasco is a great example of not putting on the Lean hat and setting out to conquer the world, nor the Scrum hat, nor any hat in particular.

I find it interesting that the Prius was held up for so long as an example of Agility and Lean principles. It was amazing. The spec was something like “fit 4 people and get 50 mpg” and the engineers surpassed the spec in an extremely short period of time.

We need to be more holistic as we deliver products. Think about the road ahead. Our code might be extensible, but is our set of assumptions? Have we tried extending it? Has anyone driven the car?

It got 50 mpg and fits 4 people, but you might want to make sure the floormat doesnt catch on the gas or worse: that the electronics are bad. Surpassed the vision, but killed people in a way that is downright ridiculous. I would like to say it is over-intellectualizing of process, but that is the pot calling the kettle black.

Everything in moderation, please, as informed and practical professionals. Let’s not have cults.

Best,

Josh