I’ve been reading a lot about lean/toyota way lately, mixing that with my past experience as an IT Consultant and throwing that up against a bit of an Ivory tower I fell into with XP that left me unable to deal with the following scenario:
You’re reviewing code either yours or someone elses right before release. you find the code strewn with anti-patterns and uncessary conditionals. You are due to ship tomorrow. The code works but is not maintainable, do you ship?
My instinct as a software developer has been “don’t ship” for as long as I can remember. I’ve taken my teams on some week long trots down engineering principle lane. While this has its place, I feel not shipping for ivory tower excellence is a critical mistake. The focus must be on satisfying the customer first and foremost, and it is absolutely critical to be aware of our limitations at the time. The most Lean and disciplined organizations (even Toyota themselves) realize they cannot do everything in an ideal way all the time. As new learning and knowledge is put together they will revisit and refine these problem areas over time.
Therefore, my approach at this time is to:
- review why the problem occurred
- strive to prevent the problem from happening in the future
- If the software is still delivering value to the customer to provide them with the product
- Tell the customer of any limitations have been found that affect their perception of value
- Work on a plan to correct the issue in the next release (which should be soon).
I’ll admit I don’t have this all figured out, but I’m reasonably certain that my old approach of delaying a release because only pristine code should come out of the team was only helpful to my ego. Engineering is fanstastic, but we’re in a service industry first.