Some Standards Are Meant to Be Changed

“We have always done it this way” may explain how a standard developed, but it does not prove that the standard is still correct.

Software development is built on conventions. Coding standards create consistency. Architectural patterns help teams solve familiar problems. Framework guidelines reduce unnecessary decisions, while established processes make development more predictable.

These standards are valuable, but they are not permanent truths. They were created for a particular technology, team, requirement, or point in time. When those conditions change, the standard may need to change with them.

Developers must be willing to question established practices without abandoning the stability those practices provide. The challenge is knowing when a standard has become outdated and when a new approach is merely different rather than better.

Standards Preserve Knowledge

Most development standards exist for a reason.

They may have been introduced to prevent a recurring defect, make code easier to review, support an older platform, improve security, or keep several developers working consistently. Even when the original reason is no longer obvious, the standard may still be protecting the system from a problem the current team has never encountered.

That is why existing standards should not be dismissed casually.

Before replacing a convention, developers should understand:

• Why it was introduced
• What problem it was intended to solve
• Which systems or processes depend on it
• Whether the original limitation still exists
• What risks would be introduced by changing it

A standard should not survive solely because it is familiar. However, familiarity is not evidence that it has no value.

Responsible change begins with understanding.

A New Version Is Not Automatically a Better Version

Software versions are often discussed as though the newest release must be the best choice. Version 5 may include capabilities that version 4.6 does not, but that does not mean every application should upgrade immediately.

The first question should not be, “Is there a newer version?”

It should be, “What has changed, and how do those changes affect this product?”

A new version may offer:

• Security improvements
• Better performance
• New development tools
• Improved accessibility
• Simpler APIs
• Longer support periods
• Corrections for known defects
• Better compatibility with current operating systems or browsers

It may also introduce:

• Changed system requirements
• Removed functions
• New dependencies
• Behavioural differences
• Compatibility problems
• Migration work
• New defects that have not yet been widely discovered

The correct decision depends on the product, not the version number.

An application that processes sensitive data may need to adopt a security release quickly. A stable internal tool with no exposure to the affected vulnerability may have more time to test. A major platform upgrade may be worthwhile for a product under active development but unnecessarily disruptive for a small application approaching retirement.

Updating immediately is not always responsible. Ignoring updates indefinitely is not responsible either.

Understand What the New Standard Changes

An upgrade should begin with investigation, not installation.

Suppose an older version of a framework encouraged procedural code while the new version prefers classes, dependency injection, and a more object-oriented structure. That change may improve maintainability, testing, or extensibility. It may also make a simple application more complicated without producing a practical benefit.

The developer must understand the purpose of the new model.

Questions worth asking include:

• Does the new structure solve a problem we currently have?
• Does it make the code easier for the team to understand?
• Will it reduce duplication or improve testing?
• Does it improve security or reliability?
• Is it required for future compatibility?
• Does it make routine changes easier or harder?
• Are we adopting it because it is useful or because it is fashionable?

Moving from procedural code to class-based code is not automatically an improvement. Either approach can be clear or confusing. The benefit comes from how well the structure fits the application.

Changing syntax without improving the design is not modernization. It is rewriting.

Backward Compatibility Is a Transition Period

Platforms often preserve older behaviour for a time. Existing code continues to work, but documentation begins recommending a newer approach.

This can create a false sense of safety.

Backward compatibility does not always mean the old approach will remain supported indefinitely. It may be a bridge that gives developers time to migrate. A feature can be supported in version 5, deprecated during the same release cycle, and removed entirely in version 6.

Deprecation is a warning, not an immediate failure.

It tells developers that the current code still works, but its future is limited. That warning creates time to understand the replacement, estimate the work, add appropriate tests, and migrate in a controlled way.

Ignoring a deprecation notice until the next major release turns planned maintenance into an emergency. Changing everything as soon as a notice appears may create unnecessary work before the replacement has matured.

The sensible response is to record the issue, evaluate its impact, and schedule the change according to risk.

The Cost of Changing and the Cost of Waiting

Every technical decision has at least two costs: the cost of making the change and the cost of postponing it.

The cost of changing may include development time, testing, retraining, documentation, deployment risk, and temporary disruption.

The cost of waiting may include increasing security exposure, disappearing support, accumulating compatibility problems, and a more difficult migration later.

Neither cost should be considered in isolation.

A change may be expensive today but far more expensive after several additional years of development have been built on an obsolete foundation. Conversely, an immediate rewrite may consume months of effort without providing meaningful value to users.

A good upgrade decision considers:

• The urgency of security concerns
• The remaining support period
• The stability of the new version
• The amount of affected code
• The quality of current test coverage
• The availability of a rollback plan
• The business value of the new capabilities
• The likely cost of delaying the work
• Other development priorities

This turns an upgrade from a reaction into a planned engineering decision.

Adaptation Does Not Mean Chasing Every Trend

Developers need to adapt, but adaptation should not be confused with constant reinvention.

New frameworks, libraries, methodologies, and architectural patterns appear continually. Some solve important problems. Others gain attention before their long-term costs are understood. A team that adopts every new tool may spend more time replacing technology than improving its product.

There is a difference between being current and being restless.

Being current means understanding how the field is changing, recognizing when an existing approach is becoming unsafe or unsupported, and learning the skills required for the next stage of the product.

Being restless means changing tools because something newer exists.

Strong developers can work with established systems while preparing for what comes next. They can maintain older code without treating it as sacred. They can evaluate new approaches without assuming novelty guarantees quality.

Sometimes the Developer Should Challenge the Standard

Standards should create consistency, not prevent improvement.

A team convention may have been appropriate when it was introduced but may now slow development, reduce accessibility, weaken security, or conflict with the current platform. When developers encounter the same difficulty repeatedly, the problem may not be individual implementation. The standard itself may need to be reconsidered.

Challenging a standard should involve more than personal preference.

A proposed change should identify:

1. The limitation in the current approach
2. The effect that limitation has on the product or team
3. The proposed replacement
4. The risks and migration cost
5. The evidence that the new approach is better
6. The method for testing the change
7. The conditions under which the team would reverse the decision

This creates a reviewable engineering proposal rather than an argument about style.

The person suggesting the change should also be prepared to document it, help others adopt it, and support the transition. Introducing a new standard without helping the team understand it simply replaces one problem with another.

Leading Change Requires Room for Failure

Some of the most valuable technical advances begin when someone questions an accepted limitation.

A developer may identify a safer deployment process, a simpler architecture, a better accessibility practice, or a way to eliminate repetitive work. That willingness to challenge convention can produce meaningful improvements.

It can also produce failure.

A new tool may not be ready. A proposed pattern may work well in a demonstration but poorly at scale. An architectural experiment may reveal costs that were not visible at the beginning.

Failure does not necessarily make the experiment irresponsible. The important question is whether the risk was controlled.

Responsible experimentation uses:

• Small prototypes
• Isolated branches or environments
• Measurable success criteria
• Representative test cases
• Limited initial adoption
• Clear rollback plans
• Honest documentation of the results

The cutting edge becomes dangerous when experimentation is performed directly on a critical production system without evidence, boundaries, or a recovery plan.

Developers should be willing to lead change, but leadership includes protecting the people and products affected by the experiment.

Developers Can Become Obsolete Too

Technical skills have a limited life when they are not maintained.

A developer does not become obsolete merely because they work with an older language or platform. Many older systems continue supporting essential businesses and require experienced people who understand them.

The risk appears when a developer refuses to learn why the surrounding technology is changing.

Someone who knows only the practices of one platform version may struggle when its architecture, security model, or development tools evolve. A developer who dismisses every new approach without evaluating it eventually loses the ability to make informed decisions.

Experience should improve judgment, not harden into resistance.

The strongest developers connect old knowledge with new information. They understand which principles remain useful, which practices depended on limitations that no longer exist, and which changes genuinely improve the product.

Adaptability protects both the software and the person maintaining it.

Longevity Requires Change

In last week’s article, Good Engineering Is Measured by Longevity, Not Complexity, I argued that software quality is revealed by how well a system survives time.

Surviving time does not mean refusing change.

Long-lived software must be able to accommodate new security requirements, browser behaviour, operating systems, customer expectations, and development practices. A system remains useful because it can evolve without losing its stability.

That requires balance.

Change too slowly, and the product becomes insecure, unsupported, or irrelevant. Change too quickly, and the product becomes a permanent experiment that never receives the benefits of stability.

Good engineering sits between those extremes. It preserves what continues to work, replaces what no longer serves the product, and adopts new approaches when the evidence supports them.

Standards Should Serve the Product

Standards are tools. They help teams communicate, reduce errors, and make software more consistent. They should not become barriers to learning or excuses for avoiding difficult decisions.

The fact that something has always been done a particular way tells us where the practice came from. It does not tell us whether that practice is still the best choice.

Developers must be willing to ask what changed, why it changed, and whether the product should change with it. Sometimes the correct decision is to upgrade immediately. Sometimes it is to prepare for a later migration. Sometimes the current approach remains the most appropriate one.

The value is not in changing or refusing to change.

The value is in understanding the difference.