Better Faster Lighter Java [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Better Faster Lighter Java [Electronic resources] - نسخه متنی

Justin Gehtland; Bruce A. Tate

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید








3.1 Understanding the Problem


Communication is a huge part of


programming. Writing better Java
won't do you any good if you're
building the wrong thing: you must understand before you can code. As
you advance in your programming career, you'll find
that more and more of your job demands effective communication. It
doesn't really matter where your requirements come
fromyour team lead, an analyst, or the customer. In each case,
your first job is to accurately gather each requirement and focus
your customer on what you can reasonably achieve with your resources
at hand. Don't plow your customer under with
enormous requirements and arcane design documents. If the customers
can't understand your documents, they
can't focus on the real issues. Like your code, keep
your requirements simple and clear.

If you don't like communication,
I've got news for you: things are going to get worse
before they get better. In a global economy, you've
got to be efficient. Increasingly, that means developers must handle
more and more of the software development process. Out of college, I
worked for the largest software company in the world. We had more
testers than coders on a project (often, by a factor of 3 to 1), and
teams of 10 planners supporting 40 developers. The overall effort was
200 developers strong. Now, that project might use 10 developers and
half the original timeframe to develop the same piece of software.
Since the development of better automation and unit testing, each
modern developer must shoulder more of the testing load. Coders also
do more design work and planning than ever before. However,
experience shows that many of those developers are not equipped to
handle many of the increased planning and analysis roles that they
face.


3.1.1 Gathering Requirements


This book would not do

its readers justice if we
didn't talk about dealing with change from a process
perspective. If you're one of those shops that tries
to do more with less, you need to do two things in the planning
process: first, weed out software requirements that
don't contribute much to the final project, and
second, weed out unnecessary work that supplements traditional
development but does not contribute much to the overall content or
quality of your code.

Many programmers believe that they need to build object-oriented
design documents like class diagrams or object interaction diagrams
in order to support development. The danger with this approach is
that you can spend too much time maintaining your design
documentation, and not enough time building working code. The best
design resources are a lightweight requirements list, working code,
and an on-site customer. A requirements document often consists of
little more than single line items, each taking less than half a day
to several days to complete. Often, you don't need
formal project management software. I've managed
requirements with expensive project management tools, word processor
documents, and spreadsheets. Low tech usually works better than high
tech.


3.1.2 Controlling Scope Creep


Once you've got requirements


together,
you'll want to keep a manageable scope. I often
spend a good deal of my time improving communication and
understanding at client sites. By far, the biggest problems I
encounter come from controlling the scope and expectations of the
project. Often, the power comes from a pocketbook, so
it's tempting for those in charge to try to add
whatever features they want, whenever they want them.
There's a necessary tension between productivity and
change. Many teams succeed because they adapt to rapidly changing
requirements, but just as many projects falter because teams fail to
adequately control scope. This is the central problem in software
development. The only way to effectively develop software is to
succeed at solving this problem.


3.1.2.1 Managing good change


Iterative development is effective partially because it allows you to
adapt. But regardless of the process that you use, your customers
must understand the overall cost of change. Whenever someone requests
significant changes, you can't threaten to beat them
with a plastic whiffleball bat. You've got to be
receptive but firm. Your first response should be something like,
"We'll try to work it in. Let me
tell you what it will cost." This type of answer
immediately gives your customer positive feedback, and also lets them
know that change affects the overall cost of the project. It
doesn't matter who the customer is. Whether your
project is internal or external, some facts never vary: development
takes money, time, and manpower. You can only do so much with a given
pool of resources.

Figure 3-1 illustrates the three ways you can react
to expanded requirements:

Reduce the remaining scope by removing an unimplemented item of the
same cost from this release.

Increase the time allotted: request more time, and ask for more money.

Increase your manpower: ask for more money, and increase your team
size.




Figure 3-1. Reacting to expanded requirements

You can also combine two or more of these options. The first method
is by far the best.

Notice that increasing hours is not a viable option. Heavy overtime
means that the project managers are not doing their job.
(Increasingly, the developer is the project manager!) Heavy overtime
usually leads to defections, mistakes, and sloppiness that cost more
in the long run. Nor should you increase your manpower in other ways.
Unless you're grossly understaffed, increasing the
size of an optimal team is going to sacrifice efficiency, and may
even delay the project further. Scheduling conflicts also cause
problems. If you frequently slip your schedules,
you're delaying the value to your customers, and
that's rarely a good idea.

By far, the preferred way to pay for a change in a release is to push
other functions out of the release. If you get into the habit of
negotiating a healthy give-and-take with your customers,
they'll get better at understanding of
what's most important to them, and
you'll get accustomed to delivering on your
commitments.


3.1.2.2 Curtailing disruptive change


The ability to react to your


customers is important,
but not all change is good. Disruptive change keeps your code out of
the hands of your customers, and code that's in the
lab doesn't do your customers any good. Disruptive
change takes several forms:

Unchecked scope creep can quickly derail any project. You must
consciously mitigate each change in scope, and do so with minimal
disruption to your team and schedule. That usually means pulling
features out for each one that you add.

Changes that are outside the central purpose of a project reduce
focus. This kind of disruptive change often deals more with
infrastructure and middleware than with end applications. For
example, I have seen customers build messaging into their persistence
frameworks, or business logic into their user interfaces. These types
of short-term compromises usually backfire.

Changes outside of the normal release schedules disrupt a team, and
changes that happen very late in an iteration (for example, after a
code freeze) are especially disruptive. In general, you improve your
ability to change by shortening iterations rather than forcing
unnatural change into an ongoing iteration. Figure 3-2 shows the cost of change at each step in the
development cycle. The sawtooth pattern is characteristic of the cost
of change in an iterative development process. It's
better to have the customer wait for the next iteration.




Figure 3-2. At the end of each cycle, especially after a code freeze, change gets more expensive

In general, certain types of changes cause more chaos than others:
late changes, large changes, and shifts in focus. The reality,
though, is that you're going to have change, and
unless you're both disciplined and lucky,
you're going to have to deal with some late change.
The rest of this chapter, and this book, deals with adapting to
change.


/ 111