Click on our Sponsors to help Support SunWorld

Applying method to
(development) madness

There are two aspects to selecting a methodology: choosing the
actual methodology and choosing the tools that support it

By Chuck Musciano

September  1995
[Next story]
[Table of Contents]
Subscribe to SunWorld, it's free!

Any methodology is just another development tool. Choose your methodology and its supporting tool suite carefully, like you would any other tool in your environment, so it fits your needs and doesn't cramp your style. Here are some guidelines. (1,800 words)

Mail this
article to
a friend

Last month, I looked at software methodology, and dissected the perception that current methodologies are magic bullets that will bring any software project in on time and under budget. The straightforward message of that column bears repeating:

There is no magic bullet for software development.

Just in case a few of you were adjusting your browsers when that last bit went scrolling by, I'll say it again:

There is no magic bullet for software development.

Despite conventional wisdom to the contrary, adopting a software development methodology does not guarantee success in the software game. Moreover, blindly selecting a methodology can hurt instead of helping.

The key to using a methodology is to remember that any methodology is simply another tool you can apply to solve the problem at hand: producing correct, well-documented, maintainable code with a minimum of effort. Your methodology is no more or less important than your compiler, debugger, or regression testing tools. If you insist on treating your methodology as anything more than this, you are setting yourself up for disaster.

This month, we'll discuss how to pick the methodology that best serves your needs.

There are two aspects to selecting a methodology: choosing the actual methodology and choosing the tools that support the methodology. Both are important, and neither should be treated lightly.


Selecting your methodology
Any methodology is nothing more than a formalized way of communicating. By strictly defining how you will describe components of your design, how those components will interact, and how those components will be further decomposed, you make it much easier for members of your development team to discuss the project and decide how to implement its various pieces.

Because a methodology defines a new language for talking about software development, the methodology you select should approximate the way you normally think and talk about software. If you tend to develop software using a traditional modular decomposition style and like to think about modules as black boxes that communicate among themselves, then select a methodology, like the traditional top-down approach, that mirrors this style. If, on the other hand, you tend to view your programs from the perspective of the data, flowing through a series of filters, gates, and processing elements, a more dataflow-oriented methodology would fit best.

If your chosen methodology is very different from your normal work habits, you may find yourself so stymied by the new style that you can never really exploit the methodology. Instead, you'll constantly be translating your old way of thinking into the methodology's structure, and vice versa, instead of getting the real job done.

On the other hand, if the methodology is too close to the way you normally do business, you may be missing an opportunity to broaden your horizons and think about things in a new way. Don't be so beholden to the status quo that you are afraid to branch out a bit. Looking at your program in a new light may reap unexpected dividends on many fronts. This is particularly true when converting from a traditional coding model to an object-oriented approach; the change in viewpoint can be astounding, with a corresponding improvement in the quality of your code.

The bottom line: choose a methodology that accommodates your current way of thinking and gives you an opportunity for growth and development.

No methodology without proper representation!
A second consideration when choosing your methodology involves how you like to represent your software design. Many methodologies use visual metaphors for the elements of the design and expect you to learn a new set of symbols that correspond to objects, functions, methods, modules, and the like. Often, subtle variations in these symbols can actually cause sweeping changes in your design.

If you are not a visually-oriented person, such methodologies may not work well for you. Conversely, visually-oriented developers may find a methodology that uses a more textual representation difficult to learn and use. Make an honest assessment of your communicative skills before selecting your methodology.

Finally, keep in mind that you never select a methodology for just yourself. You are selecting a tool for the team, one that will strongly impact how team members communicate. You need to consider how each current team member (and, if you're expanding, each future team member) best communicates and develops code before choosing your methodology.

Choosing your weapons
Having a methodology in hand is only half the battle. Invariably, you'll need a set of development tools that help you build your software using the principles and rules of the methodology.

Typically, these tools include some sort of design capture tool, a code generator, report generators, and consistency checkers. (You might get some configuration management tools as well, but usually these are not part of the methodology tool suite.)

The most important tool is the design capture tool. You'll use this to create your software design and modify it as your application evolves. You'll spend many hours using the design capture tool, so it should be easy to use and easy to learn. Above all, it should not become an impediment to the design process.

Most design capture tools are graphical, since most methodologies are graphical in nature. In fact, almost all methodologies boil down to creating boxes of various shapes and sizes and connecting them with lines of various shapes and sizes. The design capture tool should ease creation of those boxes and lines, using the mouse and keyboard in logical, efficient ways. Its use should be obvious to even novice users, and should not impose a long learning curve.

Choose a methodology that accommodates your
current way of thinking and gives you
an opportunity for growth and development.

Some design capture tools produce agony. They sport all sorts of strange modes, weird menus, non-intuitive (to me, at least) mouse behavior, bad graphics, and poorly designed icons and symbols. Some of them can't even zoom in and out on the design view. Beware.

Make sure you can use the design capture tool as easily as you use your favorite text editor. Sit down and capture the design of a simple application. Determine where things were easy and where things were difficult. Let the vendor know of your dissatisfaction. And above all, don't choose a capture tool that makes designing painful, tedious, and error-prone.

Design ups and downs
Don't overlook the fact that design comes from two directions: down from the system architects and up from the developers. Architects capture the design using the approved capture tool. Developers capture the design using source code. If the design tool cannot integrate source code into a top-level design, you have lost half your design input.

The reality of development is that the design evolves at a high level and is eventually committed to code. That code is compiled and somehow, in spite of the fabulous methodology, has bugs. Those bugs might be fixed by revisiting the design and moving some boxes and lines around. More likely, the bugs are fixed at two in the morning by someone who has had entirely too much coffee and too little sleep. Those changes to the source code may critically change the entire system design. The design capture tool must be able to accept that modified source code and integrate it into your design.

If you choose a tool that cannot do this, at some point your code will begin to deviate from your design. Since your company most likely is in the business of selling compiled code and not pictures of boxes and lines, you'll have no choice but to abandon your beautiful design and start working with the ugly, mostly machine-generated, source code.

My generation?
Which brings us to code generators. At some point, you'll click a button and your design tool will spew forth reams of code. That code should be easy to read, easy to understand, and use the same names you used in the top-level design. It should be accepted by your favorite compiler, and be amenable to debugging by your favorite debugger.

Often, the code produced by these tools is unwieldy, ugly, and horribly structured. After all, the design tool is nothing more than a compiler, turning boxes and lines into while and for loops. If you've ever browsed the assembly code produced by your favorite compiler, you'll know it can be tough to match it up with the source code. You must be able to match the code generated by your design tool with the actual design, and you must be able to edit it and feel comfortable that you've changed the right thing.

Before buying any design tool, make sure you (or your lead programmer, if you won't be actually dirtying your hands touching the code) examine the generated code. When examining this code, keep reminding yourself that you'll be staring at similarly styled code during your development cycle, as the clock ticks inexorably towards First Customer Ship.

Reports and consistency
While design capture and code generation should be given your most critical inspection, the report generators in your tool suite need to get the approval of your management. That's because this is the tool you'll use to produce the reams of viewgraphs, charts, and tables that will be demanded of you on a weekly, if not daily, basis. Of course, you don't let them examine the tool directly. Instead, generate a bunch of reports and float them by your supervisor. See what they like and what else they ask for. Make sure you can create all these reports using the tools provided. Don't be caught having to measure some arcane metric du jour like "parameters passed by reference to functions whose names begin with a vowel" manually.

Finally, make sure the tool suite includes some sort of consistency checker. Most captured designs are enormous and cannot be completely understood by just one person. Often, a small difference in the way two designers use the capture tool can cause all sorts of small problems in the final design. Having a tool that can look for and resolve these differences can be a real lifesaver.

Make the right choice
A methodology can really help you get your job done right, if you put things in the proper perspective. Make sure you pick a methodology that matches your development style. Always remember that the methodology is just another tool in your toolbox to help you get things done. Select tools that work well, don't get in the way, and support every aspect of the development process. And most importantly, never think that the methodology will replace smart, motivated, enthusiastic people.

Click on our Sponsors to help Support SunWorld


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's URL: Reach Chuck at BIO chuck

What did you think of this article?
-Very worth reading
-Worth reading
-Not worth reading
-Too long
-Just right
-Too short
-Too technical
-Just right
-Not technical enough

[Table of Contents]
Subscribe to SunWorld, it's free!
[Next story]
Sun's Site

[(c) Copyright  Web Publishing Inc., and IDG Communication company]

If you have technical problems with this magazine, contact

Last modified: