Thoughts on The Lean Startup

 I had the opportunity to get a review copy of The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses by Eric Ries. I learned a few things from the book, but the most surprising thing was that what, on the surface is a book targeted at business people, entrepreneurs in particular, actually had a lot to offer developers and project and product managers who work at all sorts of companies. In addition to reviewing many of the lean principles and practices familiar to anyone who takes agile software development seriously, this book also makes a case for how practices that work for developers (like testing) also make a great deal of sense at the business level. To be sure the tests are different, but the idea of having measurable expectations is something all agile developers who have written a unit or integration test should be familiar with. Eric Ries shows how this same approach makes sense for determining the direction a business should take.



This book provides guidance on the tools to use to answer the question "are you building the right product" quickly. Even if you are on a team in an established company -- even if your are building tools for internal use -- concepts like the Minimum Viable Product can be useful to you immediately.

In spite of the book's business oriented focus, it makes clear the importance of good engineering practices to build a sustainable product development environment. This book can benefit those who work in startups and anyone who works on a team that wants to have the impact of a startup.

Why SCM Patterns is in Patterns Format

I recently had an opportunity to speak to an undergraduate software engineering class. The professor for that class, Danny Dig has a very interesting practice of asking practitioners to speak to the class over Skype when an appropriate topic presents itself. Danny invited me to join then when they were discussing software configuration management and version control.

During the session Danny asked me why we used pattern form for the material in  Software Configuration Management Patterns: Effective Teamwork, Practical Integration was in pattern format. At the time I might have quickly answered that I was interested in patterns and the book was based on patterns we'd written. But aside from being a too flippant, and not terribly profound. that answer isn't actually right.


There are two aspects of patterns that make them well suited for software configuration management practices, especially those at a team level:

•  Patterns describe things people have done successfully, and we wanted to document the practices that worked well, and which, when they were missing, caused problems. We wanted to catalog the things that we found ourselves explaining again and again in different organizations. If you read the book,  much of what you read will sound obvious. But it's only obvious if you know it, and may people don't.
•  The pattern form makes it very clear than everything fits into a context, which includes other decisions you've made and the environment your working in.  People often get captivated by solutions without really thinking about whether the solution is right for he problem they have, and what else you need to do before and after to ensure success. 

Too often people associate SCM with tools. and techniques without considering what techniques work well for the team. SCM Patterns puts the solutions in context with your organization, process, and architecture and (hopefully) provides you with some guidance on the steps to build an environment where people can code together effectively.

The other thing I realized shorty after writing the book is that, while the book was in it's final stages just as the Agile Manifesto was being worked on, the book had a lot to say about agile collaboration. The SCM Patterns book, to me, is really about how to work together more effectively. SCM is just the means.