John D. Mitchell's Blog

Successive Embellishment

Growing up, one of the things that I was taught was that embellishing was wrong. That was confusing to me since the actual definition of embellish is: "To make beautiful, as by ornamentation; decorate." Of course, my mom and various "teachers" really meant to teach me that telling lies is a Bad Thing(tm). Alas, like so many of us, precision in language isn't much of a priority — we over-rely upon the communication of our emotionalism to impart our intent.

In Spiral Learning, Kathy Sierra talks about the need to and benefits of iterating quickly through the entire cycle of learning. If I may be so bold, what she's talking about is the notion of Successive Embellishment. Basically, start small and simple and then iterate. But, rather than the traditional view of us following the spiral inward, tighter and tighter, we're going the other way: we follow the spiral outward, embellishing what we've already done — not only makes it more beautiful but also more valuable.

Your homework, should you accept it, is to connect Successive Embellishment with the notion of Passionate Curiousity.

Comments

• They say that to a man with a hammer, everything looks like a nail.
  Well, my current hammer is the thing they teach in good old comp sci 101 - the "divide and conquer" strategy. I've been thinking about what works in programming, and what doesn't work, and it seems like just about everything that works is an example of divide and conquer.
  Binary searching and sorting of course being classic application of that, but other things, such as quickly tracking down defects. Someone will post a code snippet and ask whats wrong with it and of course I think that they way they should solve the problem is to break it down to the essentials (divide), simplify it, and only once they have solved the simple should they add embellishments (conquer).
  Your perspective might be different, you might see divide and conquer as being an example of simplify and then embellish... thats okay, we can both be right :D
  As for the spiral methodology, I seem to remember one from my comp sci textbook, but it had to do with addressing the largest/highest risks first, rather than being about iterations. They made a compelling case - that engineers left to their own devices will choose to tackle the easy or fun parts of the task. If we apply the pareto rule then the 20% that takes 80% of the time is probably the hard bits, by leaving them till last you create a false sense of security, and the project will either fail, or will fail to meet its deadline, or the programmers will have to pull 'a few' all nighters to get it done.

  Posted by: rickcarson on February 14, 2005 at 08:09 PM

• Rick, there's definitely a lot of different ways to apply divide and conquer to just about anything. A suprisingly large number of them are even useful. :-)
  In my mind, your examples are getting at the fact that there's another side to the coin... Successive Embellishment is inextricably tied to Successive Refinement (--> Successive Development(tm) :-). A modern classic example is the Write Test, Write Code, Refactor cycle.

  
  As you also mentioned, there's a number of different "spiral" XYZ's floating around. I'm a big fan of using risk to our advantage but that's a whole 'nother topic. In terms of spirals and the false sense of security, how do you deal with that risk?

  Posted by: johnm on February 15, 2005 at 10:21 AM

This work is licensed under a Creative Commons License.