5.2 Understanding the Big Picture

It probably won't surprise you to learn that many—even most—decisions 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 category—or more rarely, the best integrated middleware suite for Java—and 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.