Un4given

Page 2 of 2

Best Practices Are Not Mature

Most programmers have had the experience of trying to modify a
system that works well, but in which it's virtually impossible to make changes
without breaking some of its functionality. Programmers call this fragile code.

Code becomes fragile when it's put together in an ad hoc fashion, without
enough attention being paid to its architecture. An architecture is the overall
structure and design of a system,. New technologies need new
architectures. For example, when Microsoft introduced "event-driven programming"
to BASIC in 1991 via its new Visual Basic development environment,
it provided powerful new capabilities, but also the potential for new
problems.

One of these problems was a poor design practice, which became so prevalent
that it ended up with a name of its own: the Magic Pushbutton. In eventdriven
programming, all a programmer does is write a few "event handlers,"
which are routines that respond to the user's actions. This technology means
that instead of having to write the core functionality for each new program
over and over again, a programmer can just add functionality to an application
skeleton that's provided for them

In the Magic Pushbutton, the only event handler that does any real work is
the one that's called when the user clicks the OK button. If the programmer
doesn't deliberately organize the program's code in a better way, then it all
accumulates in this one routine, which ends up as a huge, unmanageable blob
of code.

Technology Experience Is Incomplete

We've seen that software technologies change rapidly. New technologies
supplant older ones every few years, and even more frequently, new versions
of existing technology appear that radically change the functionality and
use of that technology. This change is necessary and inevitable.

Moreover, developers work with an enormous range of specialized third party
software components. Experience with these components can rarely be
carried over into future projects, because those future projects are unlikely to
use the same third-party components. Experience with enterprise application
frameworks is similar; these frameworks are so extensive that different projects
that use the same framework may well use totally different parts of it.

Whatever a developer was working on even three to four years ago is
unlikely to be of any direct use today. So what use is an experienced developer?
Is it true that every significant new piece of software is written by
developers who are essentially novices to the task?

It's true that long lists of desired technology skills, which are so prevalent
in IT job advertisements, are virtually useless. The bulk of the technical
knowledge required for a project will normally be learned on the job. However,
the "softer" skills that make one a good developer, or even a good team leader
or architect, do apply from one project to the next, and can accumulate over
time. These skills include the software development best practices. Sadly,
these skills are rarely mentioned in job ads.

Software Development Is Research

As noted in previous points, the requirements for a piece of software will
invariably be incomplete. There will be conceptual gaps that must be filled,
and there will be assumptions that aren't justified and aspects that just won't
work. Because clients aren't software experts, they won't always be able to
distinguish between what's possible and what's not, or know what trade-offs
are available. They need to work with the developers to discover this.

This means that the development process is a process of discovery?
progressively finding out the exact character of the software that will meet the
customer's needs. Developers must combine analytical and creative skills to
find out what their customer really wants (even if the customer's description
is confused and incomplete) and invent ways to combine these requirements
into a system that's logically consistent and easy to use.

We can't take it for granted that a given software tool or component will
work as we expect it to, or do everything that we need when we use it to create
our software. Even if the product chosen is mature and well regarded, and
even if the developers have used it before, because of the complexity of software,
you can rarely be sure that it can be used for the functions and circumstances
that are unique to a particular project. You can't tell if it will do the job
until you've actually made it do the job, and have seen that it works.

So software development is also a process of discovering whether and how
the chosen technology can be made to perform the role that's required of it.
Sometimes it will work as expected. Sometimes it won't, but there's a workaround
that takes more effort than originally planned. And sometimes the
technology just can't do what's needed. Software projects rarely run smoothly
from beginning to end. They frequently encounter setbacks and dead ends,
simply because of the scope of the unknown. In a very real sense software
projects are simply the process of discovering the unknowns: once the
unknowns are known, then the project is effectively at an end.

Construction Is Actually Design

Bridge building consists of a sequence of well-defined phases. The first step is
to perform the planning and design, which results in a set of plans and blueprints
that can be signed off. Once these tasks are completed, then construction
can start. The construction phase largely consists of well-defined,
repetitive tasks that can be accomplished by less highly skilled workers.

In contrast, software development is a process of research, so at no point
can definitive plans be drawn up. The more definitive you try to make the
plans, the more flawed they'll be, and the more labor there will be in revising
them to meet changing circumstances. As the shape of the software becomes
increasingly clear over the course of a project, the design of that software must
be revised again and again

If tasks can't be well defined, then we can't cleanly separate the design
and construction phases. Indeed, there's no construction as such; there's only
design on smaller and smaller scales.

Programming is more than just writing code. Each step requires the developer
to analyze some portion of the problem and design some aspect of the
solution.

Change Is Considered Easy

Last-minute changes to requirements are rare in bridge building because the
consequences are so severe. If you discover during the course of a project that
the foundations are in the wrong place, then it takes considerable effort to dig
them out and rebuild them in another place. This is obvious to clients and
contractors alike.

Compare this to software. Software is soft, by definition. Any part of it can
be changed at any time, just by rewriting that portion of the code. We expect
that bugs can and will be fixed wherever they appear in the system, as indeed
they are. Anyone who has written macros for Microsoft Office, or learned how
to write small programs at school or at a university, knows how flexible software
is and how quickly you can make substantial changes.

It's true that substantial changes can often be made quickly and easily, but
to properly implement them you really have to revise the architecture of the
software so that it gracefully supports the new functionality; otherwise you'll
just create a mess and make the software more fragile.

Change Is Inevitable

We've seen how software development is actually a process of design from
beginning to end. It includes design work to accommodate requirements
whose details become clearer as the project progresses, and design work to
reflect what's learned about the tools and components used to develop the
software. The process of software development is one of continuous design,
and therefore of continuous change.

Moreover, clients see how easily changes can be made, and expect that
they can change their minds at any point. Indeed, they often do, as they learn
more about what their budding software can achieve for them.

Change is inevitable, and if a piece of software isn't built to support change
then it will fall apart even as it is being built. The quality of software shows
itself when the software is first extended or modified. If the process of development
becomes one of extension and modification, then any software that
resists change will have a difficulties.

About the author


I have worked in Information Systems since 1995, including adult with
ExtremePaychecks and RageCash (2001 - 2006). As a consultant my goal is to
decrease the viscosity of the development process by discovering and
implementing new methodologies.