Is Systems Development An Art Or A Science
Computer/Internet/Software Articles
Submit Articles Back to Articles
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.
About the Author
Tim Bryce is a writer and management consultant with
M. Bryce & Associates
of Palm Harbor, Florida and has over 30 years of experience in the field. He is
available for lecturing, training and consulting on an international basis. He
can be reached at
timb001@phmainstreet.com
Comments and questions are welcome.
His writings can be found at:
http://www.phmainstreet.com/timbryce.htm
Copyright © 2008 by Tim Bryce. All rights reserved.
Follow us @Scopulus_News
Article Published/Sorted/Amended on Scopulus 2008-03-16 21:51:40 in Computer Articles
