![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
History is philosophy teaching by example. -- Dionysius
I just returned from an eighteen-day jaunt around Italy with my wife; the trip gave me a nice break from the academic environment and some time to think without having a computer screen in front of me, demanding attention.
As we went from one magnificent masterpiece of painting, sculpture, or architecture to another, I began to feel that I was looking at something very familiar. While wandering through the ruins of an ancient town that was buried by the famous Vesuvius eruption almost 2,000 years ago, I was awed by the structures' advanced design and utility. It dawned on me that there is a strong connection between these great accomplishments of the past and the few great software systems we have today. I'm talking about masterpieces of coding that you can't help admiring for their style, structure, and concise expression of a solution to a complex problem. We've all seen such systems; some of us may be lucky enough to have written one or more.
I'm not the first person to relate our craft to that of past masters. In his excellent book, Software Craftsmanship: The New Imperative, Pete McBreen compares developers to craftsmen of the great Medieval guilds, classifying them as either master craftsmen, journeymen, or apprentices, each with a unique role to play in creating an artifact. This analogy is a great one, as far as it goes. But I see deeper links between artisans of the past and present that I'd like to explore with you this month.
During the Renaissance in Western Europe, artistic giants like Michelangelo had an impressive breadth and depth of knowledge that transcended the boundaries of a single craft, such as painting or sculpting. They were often accomplished architects who understood both aesthetic and scientific design principles. Leonardo da Vinci, the premier example of a Renaissance man, was an artist, scientist, architect, weapons maker, and much more. Michelangelo, in addition to painting the Sistine Chapel ceiling, was also the dome's architect (Figure 1). Although the structure was not completed until after Michelangelo died -- Bernini and other masters carried out his design -- it is a magnificent example of Michelangelo's brilliance in art, architecture, and engineering.
Figure 1: The dome at St. Peter's Basilica, designed by Michelangelo
For these Renaissance giants, mastering each craft meant learning its fundamental principles and then tirelessly applying them -- and eventually expanding and improving upon them. Inherent talent was important, but it could not shine through without a lot of hard work. As Thomas Edison said, "Genius is one percent inspiration and ninety-nine percent perspiration."
Today's great software engineers and computer scientists -- Knuth, Booch, Thompson, Ritchie, Jacobson, Parnas, Beck, Fowler, Rumbaugh, Wirth, and Martin come to mind -- also began by learning fundamental principles and then applying them with great attention to details until they achieved an understanding of how things work best. Most of them have worked not only with software but also with hardware architectures (remember the original Rational Ada computer systems?), in other scientific and mathematical disciplines (just look at Knuth's books), and in soft sciences, such as psychology. For them, this cross-fertilization of disciplines has inspired unique and brilliant ideas that sometimes seem deceptively simple.
Methodologies, such as XP and the Rational Unified Process,® or RUP,® for example, might seem intuitive at first glance. But their creators carefully distilled even the simplest parts of these approaches from multiple experiences, and each has a particular purpose.
As in a great work of art, the parts interact subtly to form an impressive whole -- in this case, an amazing portrait of effective software development.
Throughout the ages, many great artists, including Michelangelo, created art on commission. To be paid and keep getting work, they had to satisfy their customers (patrons). Most of the time they succeeded, but there were notable exceptions. For example, when Michelangelo showed Lorenzo Medici his statue commemorating one of his patron's family members, Medici complained that it didn't look at all like the deceased. Confident that his art would endure, Michelangelo replied that a thousand years from then, no one would know the difference.
Just as Michelangelo created art for a purpose, we create software for a purpose -- usually for a paying customer. Only when the work is defined and the price agreed upon does the design begin in earnest. Renaissance masters made preliminary sketches of their work, or even models if the project was a large sculpture or building. Before starting on the "production" version, they made sure there would be no surprises. It would not do to have the arm fall off a statue because the shoulder could not bear the weight. I was surprised to see how many statues have visible supports, which detracted from the aesthetics. Not Michelangelo's David, though. That masterpiece has no supports. There is nothing extra. Everything has a place and a purpose.
The same might be said for certain brilliant software systems. I have had the privilege of working with many developers who were masters of their craft. These people could envision the final system from the outset of a project. Like a Renaissance sculptor who made sure that each fold of the fabric on their models was just right, these developers were scrupulous about creating clean, accurate models that translated into sleek, efficient systems in which every feature has a clear purpose and adequate support.
Balancing people, process, and tools
If you've read my past articles or attended my talks, you probably know that I view software development along three axes: people, process, and tools. People perform the work according to some process -- whether it is formally defined or not -- and tools support both the process and the people. These three axes also defined work in the Middle Ages, the classical world, and even earlier.
As you probably know, many of the world's great paintings were done by teams: The master did the design and painted key parts; the remainder was assigned to journeymen and apprentices.
On these projects, effective management was critical. The masters understood that they could not be prolific without employing others, but they had to monitor quality so that patrons would think the results were worthy of the "celebrity" prices the masters charged.
Software development is also a "team sport." Often, one person may have the vision and undertake the design, but it takes many people to bring a system to life. We have all seen brilliant developers who fail as team members because they fear that others will spoil their grand design. Looking at artistic masterpieces by Titian or Caravaggio might help them understand the value of working with a talented team.
Every art and craft requires different techniques to bring the materials to life. Painting with watercolors is quite different from painting with oils, for example. Each craft also requires a different process. One gallery we visited in Florence was exhibiting paintings on wood from the late Middle Ages that were gilded with gold leaf. The exhibit described how exacting the gilding process was, explaining that any deviation would result in a ruined work. Of course, not all artistic work demands this degree of precision. Sometimes the creative process can be much looser. The same is true for software development: The rigor of your process should vary according to the type of product on which you are working.
When it comes to tools, the analogy between sculpture and software is easy to grasp. Obviously, you don't just start chipping away at a block of white marble with any old chisel. You need precision tools to create a masterpiece. The same is true for an expensive custom application; as the complexity increases, the quality of your tools must also increase in order to produce the desired results.
If you want to see a perfect confluence of people, process, and tools in action, drop by the town of Cremona, not far from Milan. Home to the great violin makers Stradivarius and the Amati family, the town still has more than a hundred active violin makers today. In one workshop, we saw a group of craftsmen cutting wood while others sanded, varnished, glued, and tuned. The care and expertise each artisan exhibited was quite amazing, and the environment in these shops seems to have changed little over the centuries. The tools are the same, and there is no factory production line (Figure 2). The visit reminded me of the rare instances when I took the time to truly craft a piece of software. The pride I feel when I remember these times and revisit the code is one of the main reasons I've continued my career in software.
Figure 2: A modern violin maker's workbench1
The great Renaissance artists were fussy about their raw materials. To find the perfect block of white marble for the David, Michelangelo journeyed to Carrara (Figure 3), where my wife and I stopped on our way to the Mediterranean coast. In addition to the awe I felt at walking the same paths he trod, I also reflected that creating a great work requires constant attention to detail. This involves not only choosing the best materials, but also selecting the right tools, bringing together the right people for your team, and taking care in every aspect of your work. The truly great artists, scientists, and software developers -- in fact, the masters in almost any discipline -- are those who understand the importance of details and take time to deal with them lovingly.
Figure 3: The white marble mountains of Carrara
I urge you to take time out from your daily work, as I did, to look at some of the greatest achievements of the past. Whether they are ancient or more recent, you will find something worthwhile to ponder and reflect upon. Spend some time wandering among things that were built before our time and listen for the lessons they can whisper to you. Market pressures and the complexities of an ever-growing set of technologies leave us with fewer opportunities to take the time we might need to produce software masterpieces. We are driven by necessity to produce software that's good enough in most instances. But don't despair. Rare chances will come your way to create works that are worthy of being called art. I hope you can recognize these and take full advantage of the opportunity.
1 Taken from Marco Nolli's Web pages: http://www.cremonaviolins.com/
Gary Pollice is a professor of practice at Worcester Polytechnic Institute, in Worcester, MA. He teaches software engineering, design, testing, and other computer science courses, and also directs student projects. Before entering the academic world, he spent more than thirty-five years developing various kinds of software, from business applications to compilers and tools. His last industry job was with IBM Rational software, where he was known as "the RUP Curmudgeon" and was also a member of the original Rational Suite team. He is the primary author of Software Development for Small Teams: A RUP-Centric Approach, published by Addison-Wesley in 2004. He holds a B.A. in mathematics and an M.S. in computer science.
Table of contents
Local resources
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
