Is Systems Development an Art or a Science?

This is an important question which is ultimately at the heart of a lot of the problems in systems and software development. There is one camp that believes development to be an art form requiring free-spirited creative types of people, and another camp believing it to be a science requiring people that are more disciplined and organized.

The difference between an art and a science is subtle but significant. An art form is based on the intuitiveness of the person performing the work, something that is difficult, if not impossible, to pass on to another human being. For example, apprentices serving under an artist may try for years to emulate the master, but may never attain his level of skill and creativity. In contrast, a science is based on a governing body of concepts and principles and, as such, can be easily taught to others. From this perspective, programming can certainly be viewed as a science as it has certainly been taught and passed on to others for many years; further, it involves certain governing principles in terms of language syntax, approaches to defining program logic and construction. Some might argue the physical design of a report or screen requires creativity, and there is a certain element of truth to this as some look better than others. But even the design of reports and screens can be governed by certain principles in terms of layout, navigation, color schemes, etc.

On the systems side, there are governing principles as well which can easily be taught to others. It too requires a certain element of creativity for such things as analyzing and solving business problems and designing work flows. I guess what I'm driving at is that science is certainly not devoid of creativity. For example, consider the sciences of architecture and engineering, all of which are based on governing principles, yet offers channels of creativity in design. Music is another excellent example of a science involving creativity. In other words, art does not hold a monopoly on creativity.

In any form of development you can either build things one at a time or in volume. Artists are excellent for building unique works of art, but it is hardly an effective approach for corporations to take who tend to build things with many people. Consequently, they are more inclined to adopt a development approach based on science as opposed to an art form. Further, maintaining a product derived from a science is easier than one based on art as you can more readily reproduce the object according to specifications.

Not long ago I wrote an article on why it is necessary to record your time during the day, specifically as it applies for project management purposes. During the article, I mentioned there is often resistance to reporting time by those people who perceive themselves as free-spirited creative types who do not like to be encumbered by such discipline. Pursuant to the article, I received some interesting responses who felt it wasn't necessary to impose too many management controls and discipline on such creative spirits, particularly programmers, that it would be viewed as a bureaucracy and nuisance as opposed to helping with their assignments. They also commented on their disdain for micromanagement; that they would prefer more freedom as it pertains to their work. Personally, I do not have a problem with this as I have always advocated worker empowerment (managing from the bottom-up). In other words, they want more decision making authority in the planning process of their assignments. This means they should also be participating in the preparation of estimates for their assignments and should be able to report back to management on the progress of their assignments. To do so, there should be something more substantial than vague generalities as to where they stand on an assignment, e.g.; "I'm 50% complete." Because of the many people participating in today's development projects, management can ill-afford to operate with vague generalities and instead needs to know early on if the worker is in trouble or will be delivering his work product early or late. This can be simply performed by recording time spent and estimating the amount of effort remaining on an assignment. This is particularly needed, if their assignment affects the schedules of others. If the worker is going to be given more freedom to layout and estimate his work, it seems perfectly reasonable to apply a little discipline and accountability regardless of the creative spirits involved, especially if other people are involved.

So, is systems and software development a science or an art? I contend that it is a science for the reasons already mentioned. As such, it can be taught and implemented in essentially the same manner as other sciences, such as architecture and engineering, who are basically in the same business as systems and software personnel except designing other types of products. True, we still have issues of creativity and managing complexity, but this is no different than the other disciplines as well. It also means imposing the same types of discipline, organization and accountability as found in the other disciplines. The problem though is this conflicts with today's relaxed office mores. One has to question if we have become perhaps too lax in our corporate cultures to the point it is having an adverse effect on productivity; that maybe some discipline and accountability might produce positive results.

Younger developers might contend that I am out of touch with how systems and software is developed these days, that they need free reign to do what they want. I contend there will always be a place for management, otherwise we will end up with the "1000 Monkey Phenomenon" whereby people are permitted to do whatever they so desire and maybe, just maybe, something worthwhile will be produced. Companies can certainly not afford to operate in this manner and, because of this, we will always need management to orchestrate development efforts in a concerted manner.

One last note, an area that greatly concerns me is the lack of standards in this industry, particularly in the area of systems. Sure we have plenty of theories of what systems are, but no definitive body of knowledge that can be applied uniformly. This is one obstacle prohibiting us from becoming a legitimate science. As long as there are multiple interpretations of the same thing, we will never realize any consistency and management will continue to perceive developers as free spirited artists as opposed to disciplined professionals.

If you would like to discuss this with me in more depth, please do not hesitate to send me an e-mail.