Skip to main content


Showing posts from March, 2010

Learning Jidoka from a production line

When you adopt an agile methodology, you first try to apply its recommendations and often you will prefer to make your own dish with these good practices. After a few weeks of practice, you won't get the expected result that the agile guru has predicated you should. Most of the time, you will be told to apply the methodology you choose without changing a thing. The Shu Ha Ri way coming from Aikido is often the concept which is proposed for learning an agile method: Shu : first phase, concentrate on all the recommendations and practices, Ha : second step, now you practice the methodology correctly and start to understand the underlying principles, Ri : you have sufficient experience to make your own decision and adapt the methodology to your specific context. You will also learn, the agile world has not suddenly erupted from the clever minds which produced its manifesto . Instead, these efficient practices have evolved over a century. Toyoda , Taiichi Ōno , Edwards Deming will b


As a product guy, working on mobile devices, I'm pretty impressed by this demo. Simple, with what you need in your day to day life. Microsoft is back on track. Thanks to Chris Pirillo for the video.

Visual design patterns

Most of the time, when guys were explaining the role of the software architect to me, I was not able to believe it would be possible to organise software development on such a division of responsibilities. I always feel the architecture is a discipline each member of a team should embrace. The " Design Patterns Quick Reference " from Mc Donaland is really useful because it allows the team to speak about the most appropriate choice in front of this great summary. But a common pitfall with these pattern design concepts is the fact people will over design and move to a solution too complex. One solution resides in the Test driven development principles where after coding the test and writing the code for them to pass, there is the refactoring step. This is the good moment to consider inserting a design pattern. Make things work, then focus on building maintainable code. Sources : Mcdonaldland : mcdonaldland » Design Patterns Quick Reference Davidhayden : Design Patterns and Ag