How to Make Change Management Work Well

Some professional programmers idolize “greenfield” coding. While their reasons might be sincere, the consequences can be harmful. That’s because software work in the “real world” is all about change. Here’s how to make it work well.

Recognize the importance of change management

The error is understandable enough: Many programmers did well in classwork, where they practiced small, short-lifetime programming with particularly clear requirements, on which they worked in relative isolation. When they encounter the fuzzier and more difficult demands of employment, it’s natural enough to dream that elimination of complications and entanglements will return them to the success of their school years.

This overlooks, of course, that the complications and entanglements are crucial requirements of what’s useful to business. Commercial development doesn’t shy away from “new construction” or rebuilding from scratch for lack of courage; it’s far more that the programming needed now always is integrative, collaborative and incremental.

Technical strength has its place. Thoughtful analysis that, for instance, reduces a SQL query runtime from 30 hours to 30 seconds, or that extracts an expert judgment from data through artificial intelligence without the intervention of an expert, remains a marvelous asset.

The employees who can exhibit such wonders have become no rarer, though, than those who can usefully curate and collate data that merit 30 hours of programming, or who know how to render the SQL-resident data so that its business significance is evident.

Adopt useful techniques to manage change

If academic courses imperfectly model business’s biggest needs, what does contribute to successful commercial development? One of the biggest contributors is normalization of change.

Adopt continuous integration (CI), continuous testing (CT) and continuous delivery (CD), not just as slogans for capability, but as routine, daily practice. Deploy so frequently and consistently that updates on Friday afternoon are no danger. That level of fluency rarely arrives because of moral exhortation or big cognitive breakthroughs; it’s the result of deploying so often and with so little drama that the team gains confidence about the outcome of the next deployment, even if completed just ahead of the weekend.

Look for smart, small increments: Rather than a single commit that implements an entire new feature, and which strains the comprehension of all the team members who didn’t originally write it, construct a bundle of small commits, each so easy and clear in isolation that they’re impossible not to understand.

Make the most of tooling: Any time an aspect of programming hints at tedium, research how it can be automated away, and what other professionals are doing to solve the same problem.

Elevate the syntactic quality of your source code by using your chosen languages’ best linters. “Use” here doesn’t mean “run when virtuous programmers remember”; it means you make it as much a part of automatic CT as all your unit tests and integration tests. Tooling of this sort doesn’t force programmers to write good source; it does, however, clear away a lot of noise and focus attention on deeper aspects of quality.

Learn to be good at at change management. Business literature offers an extensive selection on organizational change management, nearly all of which applies to programming. Change is so central to software development, in fact, that its management can be seen as tech’s fundamental challenge. 

Avoid excessive complication. Be aware of programmers’ great hazard in the area of change management: excessive complication. Sensitivity to change deserves to be no excuse for extreme abstraction. Well-meaning programmers sometimes think they “future-proof” code by making it highly configurable or “powerful,” but for most situations, simplicity is a better basis for successful change. A few projects in the world benefit from writing factories for grammars for domain-specific languages, or otherwise layering abstractions high; it’s far more frequent, though, just to invest 20 minutes in a manual reformatting that achieves a desired effect. Automate, and generalize, but in a balanced manner: That’s the wisest way to keep up with change.

Get everyone confident with change

Become comfortable with CI, CT, and CD; apply them daily and even hourly in your own programming. Practice reviews and other team activities that diffuse knowledge. Learn from programmers working on other projects, as well as all the non-programmers — QA, product managers, user interaction specialists and so on — with a direct stake in your application.

Rather than source code so perfect it never needs to be touched, aim for your own capabilities to be so strong that you’re confident you can handle any change your project needs.