AGILE IN ACTION

Jason Yip is distressed by the lack of consideration given to testability and maintenance by many enterprise architects and their followers. It's not all about scaling and vendor relationships, but doing the simplest thing, building features only when they're needed, and keeping options open while deferring commitment until the latest responsible moment is not the staple diet of the enterprise architect. 'Anticipate' is their word. Justify why you're not building a generalised solution that caters for everything and can handle every conceivable change. The problem with this approach is that it introduces complexity and that complexity requires significantly more maintenance. Keep it simple, stupid . Justify why you're building more than you need to. Justify why you're building something that is expensive to test. Remember: It has to work. It has to be easy to verify that it works and keeps working. It has to be maintainable. A single change should be a single change. It has to be understandable otherwise it won't be maintainable. Less things built means easier to maintain.

Simplicity is the ultimate sophistication - Leonardo Da Vinci

Why is simple so difficult? was a goldfish-bowl discussion facilitated by Nat Pryce and Jonathan Clarke . It was an energetic session with people pinging in and out of the bowl at a rate of knots. Here's some of the things that were said: Simplicity emerges. We should be saying - have the simplest thing, not do the simplest thing. Dan North said simplicity is clarity of intent. How clearly can I express intent? If redundant code supports clarity then I'm ok with that. I like 'clarity of intent' as a definition for simplicity.

In the second edition of Extreme Programming Explained, Kent Beck defined five values:

David Crow writes about rules for simplicity. I like number 10: