The Psychology of Bad Code Part 5 – Shiny New Tech

This is a series. The first blog post is here, #2, #3, #4, and this is the fifth.

The behaviour: Shiny New Tech

Using a brand-new technology, language, and/or framework, even when it’s not necessarily the best thing to use. Especially if it’s untested, and there’s little guidance or tools available for it. An obsession with using what’s new, over what’s best for the situation.

What this looks like in the real world

• Jumping to a new framework, library, language, or tool because it’s exciting, popular, or “the future”
• Wanting to use something new before fully understanding how it works
• Replacing stable, working systems with newer ones without a clear reason
• Forcing ‘the cool new thing’ as a project requirement, when there’s no technical reason for doing so
• Choosing tools based on hype, not security, maturity, stability, or supportability
• Associating your value as an engineer with how current your tech stack is

This often shows up when we want to stay relevant, have something to prove, or when everyone around us is talking about the same new thing.

Behavioural biases at play

• Novelty bias: New things feel more exciting, more interesting, and often better, even when they aren’t (from a security perspective this is rarely true)
• FOMO (fear of missing out): We worry that if we don’t learn or use this new thing, we’ll fall behind or be left out of something important
• Status signaling: Engineers often (whether we admit it or not) tie reputation to using modern tools. “A 10X engineer would use this, so I will use it.”
• Present bias: We prioritize immediate work over future clarity, even when we know it will cost us later. We use present bias to justify the decision, while one of the first 3 is the reason for the decision.

These biases aren’t bad. Staying current matters in tech. Learning new things is part of the job. We need to be aware of new tech. But this can also absolutely lead us in the wrong direction.

Why this behaviour makes sense in the moment

Tech moves fast. Really fast. Even faster now with AI. Too fast.

New tools promise:

• Better performance
• Less code
• Easier development
• More “modern” architecture

And sometimes those promises are true.

On top of that:

• Job postings tend to reward newer tech experience
• Conferences, blogs, and social media amplify what’s new, not what’s stable, normal, or reliable
• No one brags about “we keep using the safe, boring thing and it’s fine”
• Learning is our lifeblood, and we are technologists, so we love learning new tech

So yeah, of course we chase new tools.

The security risk

Security rarely keeps up with new tech. So, so rarely is it even any sort of priority for those building it. 

New frameworks, by definition:

• Have less real-world testing
• Have fewer security reviews
• Have undocumented edge cases
• Have smaller communities catching issues
• Have less support in every possible way

And most importantly: We don’t even know how they fail yet.

When you adopt something new, you are also adopting unknown risk.

In case that’s not enough for you:

• Security guidance is limited or non-existent for new tech
• Best practices haven’t stabilized
• Developers are learning while building production systems

The combination is… non-ideal.

Solutions:

Secure Defaults

Add a required security review as part of any new tech adoption process. If you do not currently have security review as part of option analysis for projects and tech adoption stop reading right now and add it. This is high value and, in my opinion, mandatory for all AppSec programs.

If you want to bring something new into the stack, great! But first:

• Threat model it
• Discuss known and unknown risks
• Security maturity
• Are there tools available to help us secure this new technology

This is a standard step, not an optional one.

Environmental Design Acceptance Criteria

I don’t know how to design an environment to protect against this issue except to lock things down so no one can install anything… And we know how popular that is! Instead, let’s look at how we decide ‘yay or nay’ on new technologies.

 Create a simple, lightweight “new tech checklist”:

• Is there security guidance available?
• Is this widely used in production?
• Are there known vulnerabilities or concerns?
• Has it been tested? If so, by who? How much? What kinds of tests? Etc. Can we see the results of said tests?
• What’s the documentation look like? Is it well supported?

Make sure there is a process or time made to ask and answer these questions before the decision is made.

Friction

Security needs a seat at this table:

• Require approval for new frameworks/tech in production systems
• Encourage piloting in non-critical environments and lower-risk systems first
• Add extra layers of security to reduce risk until you’re sure it’s safe

Social / Cultural

We don’t want to be a ‘Debbie downer’ and naysay all new technology as bad. If we do this, people will start going around us. We do not want this. I’d rather have them run me over, but know it’s happening, then have them go behind my back. At least then I can prepare.

This means we need to be careful when we discuss new tech. We may need to remind ourselves:

• New tech is not the enemy and it’s not always bad
• This is likely happening whether we like it or not, so let’s figure out how to do it as safely as we can
• Only die on hills that are worth dying on

I asked the AI for feedback and suggestions for this section. It suggested ‘celebrating stability’, but I don’t think starting an unprompted discussion about “how nice and reliable .Net is” would change any minds about adopting a ‘cool’ new framework. I think it would be awkward and feel forced, but if you disagree, I’d love to hear your thoughts.

Conclusion

Using new technology isn’t necessarily a problem. But we must do so safely, with all the proper security steps.

Up next, avoiding documentation. Fun times!