Chapter 3. Understanding the Management Perspective
FAQ 3.01 What is the purpose of this chapter?
To improve the effectiveness of developers by presenting the management perspective on common software questions.
All too often, developers live in their own world of technology and miss the “big picture.” As a result, they lose credibility with decision makers by emphasizing peripheral issues, or they fail to sell a laudable idea because it was not packaged and presented effectively. Since this book aims to improve the overall effectiveness of developers, we will show how decision makers think by drawing on our own experience as managers and executives, as well as the insights we've gained from others and from work we've done as architects and developers.
FAQ 3.02 What is the core message of this chapter (and this book)?
To increase effectiveness by being business-centric rather than technology-centric.
Technology does not exist in a vacuum. It exists in a complex milieu of customers, budgets, competitors, organizational goals, product features, time to market, and so on. In this world, there are no context-free notions of “good” and “bad” (and anyone who proclaims one technique or method as universally bad or another as universally good is hopelessly technocentric). So to make good decisions we need a context, which is defined by looking at the business objectives and using them to help define what “good” means (and what “bad” means). With the context properly defined, it is possible to evaluate technology trade-offs in a manner that always keeps the business objectives in mind.
This message is in stark contrast to what technologists typically preach. For example, technologists typically promote one design method (or inheritance model or programming language) over another using a universal notion of “good” and “bad”—they have an answer even though they don't know what the question is; one size fits all. It's as if they are saying, “I know what's good for you even though I don't understand your world.”
This does not imply that different technologies don't have different trade-offs—they do. But the trade-offs can be evaluated only by looking at the business objectives and requirements. This leads to the following high-level process.
- Examine the business objectives (why the application/system is being built).
- Then examine the requirements (what the application/system should do).
- Then examine all the alternate design techniques (how the application/system should be built).
And always make the less important decisions (such as various design techniques and ultimately the programming techniques) in light of the more important decisions (such as what the system is supposed to do and, even more important, why it is being built in the first place).
FAQ 3.03 Why are the managers in charge rather than the developers who understand technology?
Because most organizations have a culture that assumes that managers are long-term and developers are replaceable parts.
Managers are supposed to understand the goals of the organization and to ensure that the goals are achieved, often using technology in one form or another. Their job is to represent the organization, and in many cases they have a fiduciary responsibility (and personal liability) if things go wrong. In their view, developers are transient and are often more interested in technology than the welfare of the organization. This may or may not be true, and the average tenure of CIOs is probably shorter than the average tenure of developers, but what's important is the perception, not the reality.
The message is that developers can increase their influence in the organization by demonstrating that they understand the organization's business objectives and that they are committed to achieving the business objectives rather than being committed to playing around with the coolest techno-gadgets. This means making sure business issues always dominate technology issues. It also means presenting proposals in terms that managers can understand, including staffing, schedules, opportunity costs, risk, and dollars and cents. Try it some time. It works.
FAQ 3.04 How can someone manage something they don't understand?
People have been doing it for years; managers hardly ever understand what they are managing.
Should the CEO of IBM know how to configure computers? Or issue expense checks? Or control the building temperature? No. The CEO's job is to understand strategy, directions, and politics; too much knowledge about operational minutiae would indicate misfocused energies. The same sort of thinking applies to every level of management, down to the first-level supervisor. Besides, if CEOs did understand the low-level details, they'd probably drive the developers crazy micromanaging them.
So managers shouldn't try to be technology experts. But how can they manage anyway? Anyone who has ever raised children has experienced keeping control without having a clue about what they were doing or what the children were saying. Managing a software project is the same thing, only the children are older and there are books that explain their lingo.
Of course, there are good managers and bad managers. Good managers lead their teams, set realistic goals, get needed resources, mentor team members, take care of administrative issues, and communicate business objectives. In other words, good managers are worthy individuals who need all the help and support they can get. So the wise developer educates the managers and becomes a reliable source of knowledge and common sense, the trusted person. Such developers protect their managers from themselves and learn to speak their language. Manipulate your managers like your children manipulate you!
FAQ 3.05 What is the most common mistake on C++ and OO projects?
Unnecessary complexity—the plague of OO technology.
Complexity, like risk, is a fact of life that can't be avoided. Some software systems have to be complex because the business processes they represent are complex. But unfortunately many intermediate developers try to “make things better” by adding generalization and flexibility that no one has asked for or will ever need. The customer wants a cup of tea, and the developers build a system that can boil the ocean [thanks to John Vlissides for this quip]. The result is unnecessary complexity, which increases the risk of failure. The intentions might be good but the result can be deadly.
Here are a few guidelines.
• Don't solve problems that don't need to be solved.
• Don't worry about the future until you're sure you can survive the present.
• Don't build things for the fun of it.
• The organization's health is more important than the developer's desire to play with the latest whiz-bang tool or technique.
• Don't add risk without a compelling and measurable benefit to the project.
• Don't invest in the future if your current project is in trouble.
Avoid the “death by one thousand cuts” syndrome by avoiding unnecessary complexity.
FAQ 3.06 What's the “Software Peter Principle”?
The Software Peter Principle is in operation when unwise developers “improve” and “generalize” the software until they themselves can no longer understand it, then the project slowly dies.
The Software Peter Principle can ruin projects. The insidious thing about the Software Peter Principle is that it's a silent killer—by the time the symptoms are visible, the problem has spread throughout every line of code in the project. Foolish managers deal with symptoms rather than prevention, and they think everything is okay unless there are visible bugs. Yet the problem isn't bugs, at least initially. The problem is that the project is collapsing under its own weight.
The best way to avoid this problem is to build to the skill level of the maintainers, not of the developers. If the typical maintainer won't understand the software then it's simply too complex for the organization to maintain. This means avoiding tricky, sophisticated, subtle, clever techniques unless there is a compelling reason for them. Cleverness is evil; use it only when necessary. Show concern for the long-term health of the system being developed.
FAQ 3.07 Should an organization use OO on all its projects?
No!
The organization is in some business other than OO programming, and technology is a means to an end. Developers might want to use OO because it is intellectually stimulating, but the people in charge have other goals and probably don't care what sort of technology is employed.
The message for developers is to focus presentations and justifications on achieving business goals, and make sure that OO is presented as an effective tool for achieving the desired business results rather than as a “cool” techie thing. Show why it's relevant. Above all, don't use the “it's the latest and greatest” argument as a justification: that angle has been overused for too many years and almost always turns off the listener. Also, don't use the “it will keep the developers happy” approach: most managers think that they are the people who need to be kept happy and that developers are transient, replaceable components.
FAQ 3.08 Can OO be ignored until it goes away?
No!
Some developers fight against OO, and some managers take a “let's wait for it to go away just like (fill in the blank) did.” But the fact is that OO and C++ aren't going away so everyone might as well get on board. There are lots of technical arguments for the superiority of this technology, but the best reason is nontechnical: this is the way the world is moving. Too many people have sunk too much money into building products based on OO for it to go away. And the only way to take advantage of the advances in software engineering in the last decade or two is to utilize a modern programming language such as C++.
So the reluctant developer should get on board. The trend is inevitable and there is nothing to be gained by fighting the inevitable. If management is doing the foot dragging, don't waste time with technical superiority arguments. Focus instead on the business issues, such as availability of tools, components, and people.
FAQ 3.09 What OO language is best?
Whichever one works best for the organization.
We believe in honesty, not advocacy, and the honest answer is that there is no single answer. What is the organization's policy regarding languages? Must there be one and only one official language? What is the skill level of the staff? Are they gung-ho developers with advanced degrees in computer science/engineering or people who understand the business and have survival skills in software? Do they already have OO skills? In which language(s)? What sort of software development is being done: extending someone else's framework or building from scratch for resale? What sort of performance constraints does the software have? Is it space constrained or speed constrained? If speed, is it typically bound by I/O, network, or CPU? Regarding libraries and tools, are there licensing considerations? Are there strategic partnership relationships that affect the choice of languages? Many of these questions are nontechnical, but they are the kind of questions that need to be answered before the “which language” issue can be addressed.
Regarding the choice between C++ and Java, Java is a simpler language and thus it is generally easier to use. However C++ is more established and allows finer control over resources (for example, memory management), and this is required for some applications. Also, C++ has language features such as destructors, conversion operators and operator overloading that can be intimidating to many developers but are essential for building frameworks that hide complexity from users. Building the same framework in Java will necessarily expose some internal complexity to the developers who need to extend the framework. So C++ will always be needed, but it isn't the only answer and it isn't always the best answer.
The messages can be summarized neatly. (1) Avoid language bigotry and language wars. (2) Never, never present language trade-offs to management exclusively using technical criteria—when choosing between languages, the most important issues are typically business issues, not technical issues. (3) Don't assume that the organization wants to be on the leading edge. (4) Don't assume that the organization has a primary goal of furthering the careers of its developers.
FAQ 3.10 What is the right approach to processes and tools?
Select processes and tools based on business considerations rather than purely on technical grounds. Buy tools, don't build them. Customize existing processes; don't invent your own.
In general, the selections should be popular enough that they'll be around in five years, should be mature, should be consistent with the organization's skill levels, and should allow hiring new people who already have the necessary skills.
An important consideration is that the process should allow local variations. IBM's WSDDM is an example of this.
Technologists waste a lot of energy arguing the virtues and vices of the various design notations. As usual, business considerations should dominate technical considerations. UML is currently the most popular notation, and it is used in this book.
The emerging method of analysis and design from the “three amigos” (Booch, Jacobson, and Rumbaugh) associated with UML is pretty good and has been well received by the marketplace.
With respect to design tools, beware of “tool worship.” Remember: tools don't produce designs; people produce designs. Tools capture the thoughts of the design team, but before the tool can add value, the design team first has to think some reasonably good thoughts. Some tools also generate skeleton code, but that's helpful only if the design is good. So tools are good, in that they capture and transmit ideas in a uniform manner, but underneath it all, design is much more human than mechanical.
FAQ 3.11 What is the right approach with off-the-shelf class libraries and frameworks?
Buy, don't build.
Unless there's a compelling reason, don't roll your own class library or technical framework from scratch. There was a time when there wasn't much in the way of technical frameworks and class libraries, and back then it made sense to roll your own. But those days have passed. Note that it is still not possible to buy much in the way of industry-specific frameworks, so there is an ongoing need to build “business frameworks,” but most technology-oriented frameworks are abundantly available.
For example, people using distributed objects should choose between a CORBA implementation and the latest variation of DCOM/COM+. It will be a hard decision, and it can't be analyzed in one paragraph, but the important idea is to avoid building a custom ORB unless there is some compelling reason to do so.