In-Depth

World Changing for Developers

Developers now must understand how development processes and decisions affect business and profitability. Is more visibility into their daily activities through IT governance a good thing?

• By Peter Varhol
• 11/09/2006

Most software developers are fiercely independent, yet highly dependent on the efforts of team members. They believe strongly in a meritocracy; the best developer is also the most respected. The world of software development is easy to picture at a high level, but incredibly difficult to understand and analyze under the surface.

From the outside the developers and the process they go through to turn requests into working software can seem mysterious, highly complex, and technical. For the most part, developers do nothing to discourage this view. There is a certain amount of job satisfaction in knowing that nontechnical management doesn't have a good grasp of software development.

Unfortunately, the combination of the inherent complexity of software development, and the success of developers in using that complexity as a tool to maintain independence, has had serious effects on the development process. On the surface, it is apparent only after the fact that development efforts have gone awry. Part of this effect is because developers are highly optimistic, sometimes unrealistically so, of their ability to bring a project back on track. However, another part is that projects, once started, have largely been independent of the types of management oversight and rigorous cost/benefit analysis under which most other enterprise projects have to face.

Past attempts to bring development teams and the actions of individual developers together have met with only limited success. Development teams accept project management as a necessary evil. You can do a work breakdown, set milestones, and work toward those milestones, but what goes on inside the work breakdown items is still pretty mysterious to the uninitiated.

Under Scrutiny
Today, developers are told to be more business savvy by understanding how development processes and decisions affect lines of business, users, and profitability. That stipulation is asking the developer to take on a more outward-facing role in explaining the development process and its impact on business. Certainly this role is important for the apparent reasons, but it also serves to help open up the development process to outside scrutiny.

However, that reason is not enough to ensure the project, its risks, and its progress are fully understood, and to many in management it doesn't address the issue of over optimism or even prevarication on issues that should be raised for management attention and perhaps action.

Now developers are faced with increasing intrusions into the bubble world that they have created for themselves. These intrusions go by a variety of names, such as "project portfolio management" and "IT governance," but the goals are similar. These software tools provide the ability for executives and senior managers to get deep into the development process and even into the performance of individual developers.

Proponents of these tools claim that that they provide the ability to manage risk in the IT environment. This type of visibility is increasingly important to the modern enterprise, which must evaluate and make immediate decisions on the latest data to better compete. It radically changes the independence with which developers have been able to work, however, and the decisions they make in building software.

Developers must have an understanding of how these tools work, what information they deliver to management, and how their individual decisions and actions affect that information. How that information is used is up to management, but developers need to be aware of what that group is seeing and how they can influence both the information and the perceptions it can create.

IT governance in the aggregate refers to the ability to track, monitor, assess, and determine risks inherent in custom software development, maintenance, acquisition, infrastructure upgrade, and a variety of other IT-related projects. While one can argue that we should have been doing these things all along, the fact of the matter is that little useful information on project status has typically been available to management decision makers, especially the line of business managers who need to satisfy a business need.

The entry point to these tools is typically a dashboard. For management, the dashboard provides a high-level view into statistics that describe the progress of a project. Managers and executives can view the business purpose of a project, the resources allocated to that project, the project schedule, and how well the project is progressing against established milestones. They generally see these summary statistics across several projects to analyze where resources are being expended and what the projected return is.

Dashboards for All
This group of managers wants to know three primary things about each project: what value does it purport to bring to the business, what is it costing, and is it on track? If at any time the answers are negative, the project is subject to change or cancellation.

Development managers and project managers also get their own dashboard. This one typically covers only the projects under their purview, but in more detail. At this level, those directly responsible for delivering software get to see some of the technical details behind the project. They are looking at bug counts, bug fix rates, unit and regression tests, function points, and other measures that provide technical managers with detailed information on progress and quality trends.

For individual developers, the dashboard provides a means of entering data that cannot be collected automatically. In many cases, this kind of data are bugs, tests completed and passed, code coverage, unit performance statistics, files checked out, and other individual measures of performance, with an emphasis on quantity and quality.

Among the products in this category are Mercury Interactive's Mercury IT Governance Center, Compuware's Changepoint, and Pacific Edge Software's Mariner. These products are typically Web-based, which means that there is no requirement for a specific platform. Most vendors that seek to offer application life-cycle management (ALM)-style solutions have pursued the IT governance platform route.

In some of these cases the developer information can be provided automatically through the application of other life-cycle tools. In other words, if you run a code-coverage tool, the results can be uploaded automatically into the governance repository where it can be aggregated and analyzed. Most ALM vendors provide this kind of automatic support for their own tools, although, it is less likely across product lines and vendors. As Web services gain in popularity, though, it will likely become possible to share data across tools and platforms in this manner.

Developers Beware?
The result of this trend is that development teams, and even individual developers, are undergoing more scrutiny than ever before. In the infamous corporate blame game, it may provide yet another tool for singling out individuals for specific attention and perhaps punishment.

Individual developer data is stored and available to be manipulated in less than honorable ways, and there are people in enterprises who know how to take advantage of such information for their own purposes. This data certainly opens up the world of the individual developer to closer inspection, and unscrupulous people can certainly use it as a finger-pointing tool. At best, it may make veteran developers uncomfortable that others not directly involved in their project can find out how their coding is progressing on almost a daily basis.

In fairness, the data collected and analyzed by IT governance software is not inherently geared toward singling out individual developers, but rather to aggregate detailed information that can be provided only through the efforts of the individuals. The information is truly useful in the enterprise's scheme of things.

The case can also be made that IT governance and project and portfolio management software is a real benefit to developers. Rather than heroic individual efforts, these software solutions may enable management to allocate resources to fix a project going off track, or at least provide an early warning before a project becomes a disaster. And it could result in the cancellation of a project that is viewed by everyone working on it as ill conceived, with the data saying something that no one was willing to say out loud.

In time, developers may come to realize that having more visibility into their daily activities is a good thing. Introducing IT governance into a project may be painful at first, but developers are nothing if not adaptable. If over time, management demonstrates that its actions are benign and for the good of the project and its business purpose, then such visibility will come to be accepted as a legitimate and necessary part of IT practice.