1. Lean Software Development
Johnathan Coraccio

2. Lean Software Development – Building and Shipping Two Versions
Author: Kate Matsudaira
December 2015
Context: Matsudaira giving advice on lean software development, encouraged by experiences she has had.
The V1/V2 Process
Understanding and catering to a programmer’s strengths
Planning a process to avoid over-engineering

3. Why I choose this article
I enjoy psychology and logical analysis
I recognize myself as a V2 programmer and was interested in the article’s elaboration and solution
Applicable across many if not all forms of programming

4. V1 vs V2 Programming Article opens with a short anecdote:
Mary and Melissa are assigned to the same project
Mary wrote sloppy code and did not write enough test cases
Melissa too a long time to do her part and spent a lot of that time on unit tests that did not always make sense
Mary and Melissa did not get along

5. V1 vs. V2 Programming
The author, as a solution, tried to encourage Mary to be more thorough and Melissa to write quick code that will be polished later
This did not work, and Mary and Melissa were miserable, as they tried hard to incorporate these suggestions
Mary is a V1 programmer
Build prototypes, hack things together, get something working
Melissa is a V2 programmer
Like second versions, test cases, polished code, thorough
How to make them work together while keeping to their strengths?

6. The V1/V2 Process It’s hard to get a product right on the first try.
A “right” product will take more effort than pushing a first version, and the product could fall into the trap of being over-engineered.
Over-engineered: Designed to solve problems or scale in a way that may not be useful
The “Lean Startup” movement advocates fast iteration and data collection to quickly pinpoint the correct requirements, needs, and uses.

7. V1 Fast, V2 Right
Work to build the minimum requirements that accomplish the business goals first; build V1
Work on V2 after; V2 will fix, improve, polish, and test the product for higher quality
Based on customer usage and feedback
This will give a platform for V1 and V2 programmers to work on the same project while utilizing the style they enjoy.

8. Why This Process Makes Sense
It reduces the risk of over-engineering
If you build the wrong thing you can correct it.
Chances are you will get to market faster.
Staffing and personnel happiness.

9. Downsides
Total time to build is more than if you just got it right the first time.
Operations can be a headache.

10. Pointers Get management buy-in. Measure everything.
The V2 will take much longer than the V1.
Have a tight feedback loop with your customers.
Make sure V1s and V2s are celebrated equally.
Be open to people being good at V1s, V2s, and even both.

11. Critique
I thought this article was very insightful and definitely applicable to me as a V2 programmer.
I like how it was presented: A programmer/manager imparting knowledge and her thoughts that were gained through experience.
Well outlined
Pros, cons, pointers
I did wish there was advice on when V2s need to program a V1 (and vise versa) or advice on working with smaller teams.

12. Questions?