|
|
Applying method to
|
 September 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}
|
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.
|
|
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-09-1995/swol-09-software.html
Last modified: