Flylib.com

Books Software

 
 
 

FAQ 3.03 Why are the managers in charge rather than the developers who understand technology?

FAQ 3.03 Why are the managers in charge rather than the developers who understand technology?

graphics/new_icon.gif

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?

graphics/new_icon.gif

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?

graphics/new_icon.gif

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.