Don't cramp my style!
Like art, programming requires creativity and flexibility. Software methodologies must acknowledge this or wind up with code that looks more like a velvet Elvis than a Mona Lisa.
August 1995
![[Next story]](/sunworldonline/icons/tb-next.gif){kind=icon}
![[Table of Contents]](/sunworldonline/icons/tb-toc.gif){kind=icon}
![[Search]](/sunworldonline/icons/tb-search.gif){kind=icon}
|
|
Don't cramp my style!Like art, programming requires creativity and flexibility. Software methodologies must acknowledge this or wind up with code that looks more like a velvet Elvis than a Mona Lisa.
|
August 1995
|
As development projects encompass larger teams and more complex problems, managers increasingly turn to software methodologies to help organize and structure their team's efforts. Too often, however, managers believe that simply forcing some methodology upon a team will result in immediate cost savings and productivity increases. Managers must realize that people, not methodologies, produce code, and quality code comes from talented, creative programmers who aren't stifled by assembly-line processes.
 Mail this article to a friend |
For most people, the word "art" conjures images of classic paintings by Rembrandt, Van Gogh, and Picasso. For a select few, "art" brings forth a decidedly different image: bright, almost fluorescent colors applied to a tightly stretched piece of thick black velvet. Because much of the subject matter of this genre leans heavily to the King of Rock and Roll, these paintings are often known generically as "velvet Elvis" images.
Viewed with disdain by the vast majority of true students of more traditional media, the velvet Elvis is nonetheless a form of art, decidedly low on the overall scale. In fact, most of these paintings are produced on assembly lines, wherein each "artist" paints the same element on the canvas, over and over. At each station of the assembly line, a person paints just the swept-back pompadour or sneering lips. No artist creates a full image; the assembly line prohibits creativity, expression, or deviation from the overall plan.
A disturbing similarity exists between the assembly line production of velvet Elvis paintings and the current fascination with software methodologies as a formal means of programming. In both cases, the work is planned well in advance by people who may not be directly involved in creating the final product. Those who do produce the final product have little opportunity to change the overall plan. Most importantly, there is no room for innovative change or creative expression as the product moves down the assembly line.
As the complexity of software has increased over the years, the task of producing software has become exponentially more difficult. Completing the job requires more people, and the problem of providing adequate communication among members of the programming team is daunting. To solve these problems and still produce bug-free programs on time and under budget, managers are turning to various software methodologies.
|
|
|
|
|
Formal structure
Any software methodology is basically a mechanism for capturing, decomposing, and structuring a programming task in such a way that more people can be applied to the problem without getting in each other's way. When only a few people produced entire programs, teams rarely needed such methodologies. Everyone on the team had a complete understanding of the problem and knew how the program had been divided among team members. Furthermore, members called upon their own creative and innovative skills to solve their portion of the task at hand.
As teams grew to encompass hundreds of members, no one person could grasp the entire problem. A way was needed to formalize the division of labor so that work could proceed in parallel by people who may never even meet to discuss the project. First developed in the 1960s, methodologies such as programmer teams, top-down and bottom-up design, and the latest fad, object-oriented development, promised to make big programming projects easier.
When used properly, these methodologies can indeed ease the development process. As long as everyone understands that the methodology du jour is nothing more than a communications medium, no different than giving each programmer a telephone and e-mail capability, there remains the understanding that actually designing and implementing the program requires creativity, innovation, and no small amount of intuition and artistic skill. When management begins to view the methodology as a complete programming solution in and of itself, problems develop rapidly.
Managing any large programming effort is a difficult task, and the desire to find a magic bullet that will make the task as easy as cranking up an assembly line is overwhelming. Who hasn't dreamed of a mythical machine into which one feeds program specifications and extracts CD-ROMs, ready to ship to customers?
Methodologies don't write code
Unfortunately, methodologies have taken on a mystical aura that leads managers to believe that simply forcing some methodology upon a team will result in immediate cost savings and productivity increases. Once the methodology is in place, warm bodies can be added to the team until the schedule is met.
What these short-sighted managers fail to realize is that methodologies don't write code; people write code. And good code requires good programmers, not just warm bodies. Creative people, people who can be allowed to think and experiment, fail and learn, draw and erase until they get it just right. People whose greatest satisfaction is to find elegant, effective solutions to hard problems. People who often find themselves shackled by a methodology that is more concerned with an arbitrary metric involving lines of code and function calls than it is with solving a problem effectively.
Some may wonder, "Who cares about artful coding? I want my code to be functional, not pretty." But creativity in coding results not in good-looking programs, but good-performing programs. Just as quality art requires creativity, so does well-written code. Coding produced in assembly-line fashion typically is not as efficient, optimized, debugged, and tuned as hand-crafted code, and therefore is less functional. In programming, a big part of the problem is efficiency, performance, maintainability, etc, and assembly-line techniques may impact these aspects of a program.
This crushing of creativity in favor of rigid methodology is a disturbing trend. By losing sight of the importance of individuals' talents and innovations, managers will end up with teams that lack the creativity and skill to write effective code. Thus, despite employing the best methodologies conceived, the team will develop a poor final product.
Debunking meths
Methodologies assume everyone is equally good (or bad) at programming, and that there is little room for creativity and innovation. In reality, every good program has at its heart a creative, innovative thought that was nurtured and expanded until it became an effective tool. A methodology attempts to formalize that kernel of creativity so that anyone can expand it into a program.
Methodologists would argue that you can still take your best and brightest programmers and put them in charge of structuring the problem. By utilizing their skills at a very high level, you make it easier for the less skilled members of the team to implement just a piece of the overall vision.
Unfortunately, the best programs cannot be captured at one level and expanded downward. Instead, they are like holograms that, when divided, retain a small copy of the entire image. Every level of program decomposition requires the same spark and innovation that the program as a whole requires at the top level. The person who codes a low-level disk access routine needs to be just as creative (many would say even more creative) than the person who fleshed out the entire project for the program that sits atop that lowly device driver.
I once had the misfortune to examine the top-down design of a software system so heavily layered that each actual programming task could simply be handed to the next person you might meet on the street to be coded, unit tested, and integrated into the final product. When I pointed out to the designers that it seemed that the program would have exceedingly poor performance due to the excessive amount of inter-module communication their design required, they assured me they had solved that problem. Pointing to the requirements document, they showed me the formal requirement that the program have excellent performance characteristics.
This is the fatal flaw of methodologies: They lead people to believe that establishing a formal specification of a problem is equivalent to solving the problem. Just as you cannot live in a blueprint of a house or drive the design drawings of a car, you cannot execute the specification of a program. You may have spent a lot of time drawing boxes and lines in a well-organized flow chart and producing a good plan for developing a solution, but you cannot implement that solution until you've written the program's code.
Use methodologies as tools
I'm not arguing that we shouldn't design in advance of coding, or that we should abandon all methodologies in favor of aimless hacking. Rather, we should recognize methodologies for what they are: communication tools. Used effectively, they can help teams of talented people come to grips with a large problem and derive elegant, creative solutions. Used blindly in an effort to tame an unruly team of programmers, they result in overrun budgets, missed deadlines, and exceedingly poor programming. Good communications is the cornerstone of any effectively managed project; software methodologies, appropriately applied, can supply a project with that needed communications infrastructure.
No methodology, however, will ever replace the skills a talented programmer brings to a team.
|
|
Resources
About the author
Chuck Musciano is an experienced software engineer and Webmaster with the Corporate Information Management Group at Harris Corp. He can be reached at chuck.musciano@sunworld.com. Chuck Musciano's URL: http://melmac.corp.harris.com.
Reach Chuck at BIO chuck musciano@sunworld.com.
|
|
|
|
![[(c) Copyright Web Publishing Inc., and IDG Communication company]](/sunworldonline/icons/b-copyright95.gif){kind=icon}
If you have technical problems with this magazine, contact webmaster@sunworld.com
URL: http://www.sunworld.com/swol-08-1995/swol-08-software.html
Last modified: