Lean Software
Development
JOHNATHAN CORACCIO
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
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
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
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


Melissa is a V2 programmer


Build prototypes, hack things together, get something working
Like second versions, test cases, polished code, thorough
How to make them work together while keeping to their strengths?
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.
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.
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.
Downsides

Total time to build is more than if you just got it right the first time.

Operations can be a headache.
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.
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.
Questions?