Guest Opinion

Developers Must Adapt -- or Die

Application lifecycle management tools are giving management better tools to peer into the development process. Your job might depend on adapting to this circumstance.

Developers tend to be highly independent people who strongly believe that they can overcome any technical issue quickly and still deliver software on time.

This optimism serves developers (and the companies they work for) well in most circumstances, but it can also be a liability in some software projects, especially in cases where the projects careen out of control. An earlier brake on some projects can be just the same to save them, but the natural optimism of developers can keep them from raising a red flag until long past the point where the project is capable of being saved.

From the outside, the developers and the process they go through to turn requests into working software can seem mysterious, in addition to being 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.

But management now has tools that provide it better visibility into the internals of the software development process, even down into the level of the individual developer. These tools go by labels such as IT governance or project and portfolio management software. These packages, which often cost hundreds of thousands of dollars, provide managers and executives with almost real-time information on milestone tracking, code quality, and even developer productivity. They incorporate algorithms to help assess project risk, forecast costs, and analyze the published schedule. They can even get down to the level of measuring the performance of individual developers against his or her peers.

The cost of this software, and the magnitude of the changes that have to occur to systems in order to install and configure it, tells developers that enterprises are serious about reining in application development costs, and making objective cost/benefit decisions on whether or not to start or continue projects. Developers should take notice.

Most IT governance software is capable of looking at bug counts, bug fix rates, unit and regression test pass rates, and build success over time. Using this software, executives who have never set foot on the development floor can assess the risk of continuing a project, and forecast its cost across the entire application lifecycle. It could even become the basis for calculating pay raises and promotions among development team members, depending on how the enterprise uses the data.

This type of visibility is increasingly important to the modern enterprise, which must evaluate and make immediate decisions on the latest data in order to better compete. But it radically upsets the traditional independence developers have been permitted. For example, a developer might not worry about a high bug count because he knows that it will come down when he switches to new libraries. The tools used to measure his project might prompt management to cancel his project before he gets the chance to switch to the new libraries.

If you have been content to take a casual approach to fixing bugs, preparing and running unit tests, it is time to consider changing to conform to the standards of IT governance and similar software. The end result still matters, but how you get there now matters too. Not recognizing it could cost you your raise, or even your job.

As with many automated tools, IT governance software can be misused. For example, you might have high bug counts because you're working on the project's most difficult and complex features. This doesn't mean that you should avoid the tough assignments, but it does mean that you have to open up your own activities to the scrutiny of management. You have to communicate the challenges you face, and what you are doing to overcome them, in clear and objective terms.

The rise of IT governance and project and portfolio management software means that software development can no longer be that mysterious process that no one in management pays in-depth attention to. Both the process itself and its results are becoming more visible to line managers and executives who are funding these efforts and depend on them to meet business needs. You must recognize that this will likely change the way you work, and adapt to give the decision-makers greater transparency into your job.

About the Author

Peter Varhol is the executive editor, reviews of Redmond magazine and has more than 20 years of experience as a software developer, software product manager and technology writer. He has graduate degrees in computer science and mathematics, and has taught both subjects at the university level.

comments powered by Disqus

Featured

  • Compare New GitHub Copilot Free Plan for Visual Studio/VS Code to Paid Plans

    The free plan restricts the number of completions, chat requests and access to AI models, being suitable for occasional users and small projects.

  • Diving Deep into .NET MAUI

    Ever since someone figured out that fiddling bits results in source code, developers have sought one codebase for all types of apps on all platforms, with Microsoft's latest attempt to further that effort being .NET MAUI.

  • Copilot AI Boosts Abound in New VS Code v1.96

    Microsoft improved on its new "Copilot Edit" functionality in the latest release of Visual Studio Code, v1.96, its open-source based code editor that has become the most popular in the world according to many surveys.

  • AdaBoost Regression Using C#

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the AdaBoost.R2 algorithm for regression problems (where the goal is to predict a single numeric value). The implementation follows the original source research paper closely, so you can use it as a guide for customization for specific scenarios.

  • Versioning and Documenting ASP.NET Core Services

    Building an API with ASP.NET Core is only half the job. If your API is going to live more than one release cycle, you're going to need to version it. If you have other people building clients for it, you're going to need to document it.

Subscribe on YouTube