Software Project Lessons from Michaelangelo
My wife and I recently went to Italy and spent a lot of time studying the life and work of Michaelangelo. For a legendary genius, his day-to-day life was surprisingly tumultuous. If you thought he quietly tolled away on the world’s greatest art without interruption, you would be in for a big surprise. In fact, the process of decorating the Sistine Chapel was so crazy, that it immediately reminded me of wild and unruly software projects. Which in turn, got me thinking about some of the good (and bad) moves which Michaelangelo–chief engineer–made.
- Estimate? One year. When Pope Julius asked Michaelangelo to decorate the Sistine Chapel, the great genius estimated that it would take him no more than a year to complete the project. When all was finally said and done, four and a half years had transpired. And this was without any beta releases. What happened?
It seems a perfect storm of factors converged to slow the project: There were political fights, there was miswork which had to be re-done, there were structural and weather problems in the chapel, and all variety of other complications. But the factor that struck me most strongly? Michaelangelo made the estimate himself at the beginning of the project before building his team of painter-assistants. At that time, he had not done frescoing in nearly twenty years (his focus had been on sculpture). In other words, he made a wild top-down estimate in an area outside his expertise without consulting the people who would actually be executing the work packages (his team). Sound familiar?
- Minimize your footprint. Renaissance artists had customers just like the rest of us, only they were called patrons. Patrons (be they the Pope or simply a rich businessman) would specify exactly what they wanted in the art which they were paying for… the number of figures… the scene, etc. Nonetheless, the artist would constantly make little, unplanned decisions about how the scene unfolds. Will that person in the crowd be a man or a woman? Young or old? Will they be smiling or frowning? What will they wear? Unfortunately many Renaissance artists (not Michaelangelo) were an egotistic bunch. They would do things like paint themselves side-by-side with the wise men in the nativity scene, or amidst the apostles in the resurrection scene. They look ridiculous, and one can only imagine what their patrons thought.
When building software, you are constantly making the same kind of little, unplanned decisions about how the application will function. Should I display the customer name with their last name first? Should the input box be freetype or should I force selection from a drop-down list? These seemingly inconsequential decisions add up over time into a huge body of collective decisions that are often made with little customer consultation. This is the developer footprint. The bigger it is, the more likely something about it will irritate the customer. Where many renaissance artists had the audacity to paint themselves into scenes side-by-side with the apostles (a big footprint), Michaelangelo rarely painted himself and when he did it was in the most humble of places. In the Last Judgement, Michalangelo painted his face on the dead skin of a skinned martyr (Bartholomew). It was so subtle, that art historians didn’t even notice the portrait for hundreds of years!
- Start in the back. As mentioned earlier, Michaelangelo had not done frescoes for twenty years when he was commissioned to paint the Sistine chapel. With this in mind, he made a key decision: He started painting from the back of the sistine chapel first so that he could improve his technique by the time he got to the front. Indeed, there are obvious differences between the frescoes up front and those in the back. When one enters the chapel from the rear door–the eyes naturally see his best work in the front first.
This reminds me of an agile development trap. With agile, the tendency is to build important, core functionality in the early iterations so that you’ve gotten something worthwhile accomplished if time or money unexpectedly runs out later. This is a wise tendency, however you usually don’t want to do the most important work in the first phase. Critical work should be done when the team is hitting stride, not when they are forming/storming. Michaelangelo nailed this.
