All parents know what is going to happen when a kid walks in a toy store. That is why, every parent knows to better set some kind of expectations and constraints (like "…you can choose a toy but only one ..., one toy or nothing.") before entering a toy store (actually any store).
Setting the right expectations and identifying all constraints can help achieve a given goal. Working within clearly identified constraints could make our solution leaner and more efficient.
Interesting example of that idea is the classical children book "The Cat in the Hat". The author of the book, Dr. Seuss, had very clearly defined constraint - the book could only use a vocabulary of 225 words, so that beginning readers could read it. Dr. Seuss used clever combinations of the 225 words and a lot of illustrations to create a very interesting long lived story.
Of course, a lot of similar examples could be found everywhere, especially in technology field. The HTTP protocol over TCP has been commonly criticized to be very constrained one and yet, exactly that constrained nature of this protocol is considered to be the main reason behind the wildly scalable and successful word wide web.
Interestingly enough, most of the advices that one could get about web application scalability would come down to embracing system constraints and rely on them rather than try to overcome them.
In fact, a constraint is a restriction on the degree of freedom you have in providing a solution. However, such a restriction on the degree of freedom could be utilized to convert complexity into simplicity. To illustrate that ask yourself how your perfect house would look like, or where you would like to be professionally in 5 years, or .... Easy questions but hard answers. The reason - prefect implies no constraints but perfect is hard if not possible to achieve. Now, if you include some constraints like the "perfect" house should not be more than 3 times your yearly salary, you would probably compromise somewhere but you would get to a solution much more easily.
Embracing constraints to help provide leaner solutions is something that I am currently excited in retrospect to Agile. In fact, this was the main difference that I discovered while exploring Lean software development in recent years. The first time when I realized that was while working with Kanban ("visual card/board"), which is an essential part of Lean Software Development and for which I would write more in my next post
Labels: agile, lean, Redpoint