Rationale
The return on investment (ROI) from
many software projects is often too low to justify the cost and
grim statistics regarding failed software projects become more
public every year. Almost every second project is
considered a failure in one form or another and those that do go
into production are often full of bugs and fail to meet the
customer's expectations. If a failed project goes to court, the
cost of litigation often exceeds the cost of the
development. Why is the
situation so bad?
The answer is complex, however it doesn't help that
most software projects proceed without a clear understanding of
the business imperatives and that analysis and architecture models do
not exist in a usable form to guide the construction phase.
Without a process strategy to
coordinate work activities a development team has no choice but
to operate in an event-driven environment where coding and
debugging are the dominate activities and conscious design work
is largely omitted. The end result is usually an amorphous design
that is either deficient or incomplete since it was achieved in a
piecemeal fashion. Also, when design blueprints are not
available, programmers end up "coding themselves into a box",
meaning they write code unaware of the structure they are
creating. Then, one day they attempt to add one more feature only
to discover that the structure they have created prohibits this.
Software developed in this manner has the following properties:
- Changes are difficult to make without causing unpleasant side-effects.
- Defect density remains high despite concentrated debugging efforts.
- Writing unit-tests is difficult and time consuming. Sometimes even impossible.
- Low life-expectancy due to the high cost of ownership.
For a new project what often
happens is that block, flowchart, network, etc, diagrams are
created with a general purpose drawing tool. These diagrams are
elaborated with lots of text and tables and the result is
organized into a thick requirements/design document and then
developers in the role of a programmer are
asked to translate the text into working software before some
real or arbitrary deadline. Sometimes, thanks to the heroic
programming efforts of key individuals and the willingness of
management to pay for overtime, these (generally small) projects
are built and successfully deployed. However, this is not a
sustainable process in the long run, especially if one of the
heroes leaves the company or burns out.
On the subject of blueprints, imagine asking a building contractor
to construct a house or a factory given only internal and
external views of the envisioned building plus some textual
requirements describing the type of floor, wall, roof, and
ceiling materials. Such information is useful for producing a
vision document or perhaps marketing brochures, but they are not
certainly not engineering blueprints and no contractor would accept a job
without them. Why? Because the chance of success without
blueprints for a complex project is very low and failure is bad
for business.
Despite all the logic and reasoning
against implementing code without blueprints, it is a generally
accepted practice in the software development world and we see
the results: cost and schedule overruns, poor quality,
un-maintainable and fragile code, unhappy customers, stressed out
development teams, and sometimes even lawyers must be called in
to sort out the mess.
Many of us have observed software
development projects where most everyone appeared to be working
furiously, but despite all the activity the project itself was
making little progress. The following factors are usually
part of the problem:
- Analysis paralysis:
Trying to understand everything about the problem before
proceeding with design and implementation can absorb all the
project resources up front, and leave you with nothing concrete
to show for all the effort and expense.
- Obsession with design:
Trying to create the perfect design before committing to code is
OK if you're a financially-independent purist or an academic
publishing technical papers. However, in real-world projects the
customer (i.e. the one paying the bills) will never see the
application enter production if the design team is obsessed with
finding the perfect abstractions.
- Hacking code: If you are
not working from an architectural design and are trying to
figure out what you are suppose to be building as you are
writing the code then by definition you are hacking. In the rush
to get a product out the door many organizations feel they don't have
time to architect or don't believe that architecting provides
them with any real value. The resulting headlong rush to code
usually leads to a software meltdown and is always disastrous in
the long run if you factor in the cost of maintenance.
- No time to test: Without
a formal testing framework and a process to enable and ensure
sufficient test coverage, software testing is normally left to
the end. The result: low-quality, buggy software.
Ironically, a problem for companies that employ people to
develop software is the fact that programming is fun. This
partly explains why most developers begin coding before they know
what it is they are supposed to be building.
Many developers are accustomed to the "shoot from the hip" approach
where discovery, invention, construction, and deployment
activities are all performed simultaneously - at the code level.
When confronted with a process that specifies an engineering
approach, many developers resist because they view this as
bureaucratic interference.
So how do you convince developers to
accept and use a process they believe will constrain their creativity
and hinder their progress? The answer is to walk them through a mini-project that
shows that the process and
tool chain will make them more productive. In short,
a developer cannot be
convincing with a PowerPoint presentation. This type of individual
will only sit up and take notice when a live demonstration of
sufficient complexity is
seen to produce positive results at the code level.
There is no shortage of books and articles on the subject of
modeling and software development processes, however, if this theory
is to be useful it must be possible to apply it to complex projects. It is the purpose of this website to bridge the
gap between theory and practice by describing and demonstrating such
a process - step by step.
Summary
Return on investment from most software projects is too low.
Structure and behavior models are
necessary to guide the
construction phase.
Furious activity is
no substitute for understanding.
Know what you are trying to
accomplish before you begin.
Failed projects can result in huge losses in terms of money, reputation, and
business.
The development process
must empower developers - not demotivate them.
Only
a live demonstration of the process will achieve
buy-in from stakeholders, especially developers.
Relying
on heroic programmers to save the day is not a sustainable
process.
If
you are trying to figure out what you are building while coding,
then by definition, you are hacking.
Producing a good design is hard work. Programming on the other
hand is fun.