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

5.2 Understanding the Big Picture

It probably won't surprise you to learn that
manyeven mostdecisions in our industry are not based on
the requirements of one or more applications.
They're made for a variety of emotional, political,
and social reasons. Some are valid and others less so.

I specialize in design reviews, at all points in the development
process. My customers typically understand the need for a good
foundation. They usually want to know the best frameworks for a
categoryor more rarely, the best integrated middleware suite
for Javaand I can certainly take a shot in the dark, for a
fee. Sometimes, there's a pat answer. For example,
hands down, you should be building with Ant and unit testing with
JUnit. Other

decisions
are not so cut and dried. You've got to take
inventory of all of the factors that affect your project. For most
projects, I don't recommend putting these into a
giant, formal document. Email or simple text documents are usually
enough, with the occasional very simple diagram. Think low-tech
first.

However you record them, environmental and political concerns weigh
heavily in the initial decisions. The best software architects
effectively balance these concerns and still exert some control over
a technical architecture. In particular, application requirements
form only a small part of the overall landscape:

What has already been decided?

Certain decisions may be made for you. If you've
already had standards set, you'll likely have (or
want) to work within that framework. You may not have to make all of
the same decisions, but you certainly don't want
your decisions to isolate you, either. Consider decisions that
ripple, such as a mandated application server that only supports
certain middleware components.

Who will build it?

More than any other factors, the experience, talent, and skill of
your team determine your success. You can make the best of each by
choosing a familiar set of technologies and languages. You can also
render experience obsolete by ignoring the makeup of your team.
Finally, you can mitigate skill shortages by getting qualified help
to review a design or mentor and train your team.

When will you need it?

It seems obvious, but your

schedule, process,
technologies, and tools must be in harmony. A heavyweight process
takes longer. New or complicated frameworks take longer to learn or
use. Certain tools make it easier or more difficult to shorten
schedules through continuous integration, unit testing, and
performance profiling.

How will you build it?

Your process may dictate your toolset and as a result the frameworks
that you have available. If you've got a choice in
this area, make sure to tailor your process to your goals.
Don't try to build space-shuttle software with
extreme programming. Don't try to build a
departmental calendar with the Rational Unified Process, as hard as
the marketing collateral or sales rep works to convince you
otherwise.

What are you trying to build?

Note that technical requirements form only a small piece of the
landscape. Once you've worked through your
environment, need, in the form of at least one technical requirement,
should drive all of your technology choices.

Figure 5-3 shows another view. Many high-level
external factors come into play before you ever weigh the technical
merits of a middleware stack or even a single framework. Your goal is
to put the appropriate weight on each of the factors. Many external,
often conflicting influences work to determine the best set of
foundational technologies for a given project. Before I move ahead to
technical concerns, allow me to rant about factors that
don't belong in the decision-making process.

Figure 5-3. More than just technical requirements shape your foundational technologies

5.2.1 Modern Cathedrals

Smart people without enough common sense have an unfortunate tendency
to build beautiful, massive cathedrals without pews, bathrooms, or
emergency exits. There's a healthy tension between a
purist and a pragmatist, and good teams need both. If
I've got to choose between the two, though,
I'll take the pragmatist every time.

5.2.1.1 Aligning your goals

Many programmers have

developed an unhealthy fear
of management, especially managers who hold the purse strings.
"Dilbert" cartoons with the
pointy-haired boss hang on thousands of cubicles around the world.
It's ironic, because developers and management
should fundamentally want the same things. If you're
a developer who fears management, you've got a
decision to make when you're choosing your
foundation. Are you building a cathedral, or are you building
software? If you're building software, then your
philosophy should be unequivocal: business decisions rule.

5.2.1.2 A hypothetical example

Here's a real-world scenario. A

director
wants to build an application in Visual Basic because the company
already owns the software licenses and new developers will be
cheaper. The team would rather do it in Java because
it's a more complete development environment and
they trust the Java community more than Microsoft. If
you're a developer on that team, you need to look at
the issue as a business decision. For a small, departmental
application, you'll establish one set of criteria.
For example, consider a complex user interface on purely Microsoft
operating systems with a relational database backend, and low-volume,
read-only access. Even with heavier Java skills on the team, the most
pessimistic Visual Basic schedule is shorter than the most optimistic
Java schedule. It would be hard for any developer to justify J2EE for
this scenario.

A medium-sized application with more intense requirements may provoke
a different answer. Let's assume the following:

The application requires a web-based user interface for customers
outside of the corporate firewall.

The backend is an Oracle database with high transaction volumes.

Schedules slightly favor the Visual Basic application.

Under these conditions, the Java developers could easily make a case
for an application with looser coupling, which would be much easier
to support and extend. Further, Java provides excellent MVC
frameworks, creating a cleaner design that dramatically reduces
long-term maintenance burdens. The trick is communication. If you
want to push a Java solution, use language and goals consistent with
your management team. You will save maintenance costs and reduce
long-term risks. You will increase quality with automated unit
testing (which is supported better on the Java side). You will offset
marginally higher short-term costs with dramatically reduced
long-term costs. You'll support a broader user
population. You can use technical arguments, but only to the extent
that they bolster business arguments.

5.2.1.3 It's all business

In either case, I say again, it's a business
decision. If you find yourself frequently at odds with management
decisions, part of the problem is likely on your end. You need to
learn to think and negotiate on their terms. Know their language and
understand their hot buttons. Leadership likes reduced costs, better
availability, fewer bugs, and more customers.

I recently visited a customer who had availability problems. They
said their management would not let them unit-test. I thought about
it and wondered why a management team would willingly slit their own
throats. It turns out the team had pitched the idea weakly, asking,
"Can we take a break from fulfilling our mission to
build in features that our customers won't ever see?
Oh, by the way, it's going to cost a whole lot of
money."

I simply asked for the same resources, using the same schedule, with
the same cost. I just reframed the request: "What if
I could improve your availability and do it with less than it costs
you in downtime today?" When availability suffers,
your customers make you feel the heat. It did not surprise me that I
piqued the customer's interest. Of course, they saw
the revised schedules and asked why some medium-priority user
requests slipped. I told them the team slipped those features to move
up availability changes. I further told them that customers helped me
make that decision.

I often find that I'm a high-paid intermediary
between teams and management. You'll be more
successful if you can do it yourself. I promise that
there's more than enough strife out there to keep me
busy. Simply align your goals with those of your management. If
you've got poor managers, go find better ones.
Life's too short to put up with unnecessary stress
every day. You need to work in a place that fuels your personal
passion.

5.2.1.4 Passion and software

Passion fuels the best and the worst of software development. Good
passion fuels healthy debate, which leads to better decisions and
software. It fuels quality and can be a catalyst for good change or a
balance against unnecessary change. It's driven from
the inside by your core work ethic, values, and goals.
It's driven from the outside by people: your peers,
leadership, teachers, and mentors. Good passion, more than any other
attribute, determines the success or failure of a career. Great
passion alone is not enough to build good software, but
it's hard to build great software without it.

There's an ugly side to passion, too. When
it's misguided, passion cripples projects and even
whole companies. Bad passion fragments a team and limits good
passion. You'll often hear words like
"religion" used to describe bad
passion. Drivers for bad passion are egotism and fear. The longer you
think about it, the more it makes sense. We're no
different from other artists. Great artists throw away a whole lot of
work. We need to do likewise. When you wrap your ego around a piece
of software, you get too attached to it to make good decisions. Teams
crippled by bad passion may still build software, but
it's rarely as good or as fast.
They'll usually fail over the long term.

A great team is a mix of missionaries on the one true path and
nonbelievers casting stones from the side of the road. If the company
is overloaded with the former, chances are good that the one true
path leads right off the one big cliff. If the company has too many
of the missionaries, you may never even get started. Find the right
mix of missionaries and pragmatists to get you to your destination.
People drive good passion. Ego and fear drive bad passion.
It's hard to make good decisions with too much bad
passion.