If You're Struggling to Hire Junior Devs, Your Codebase Might be to Blame

If you’re wondering whether this blog post is really for you, ask yourself a few questions:

• Is my core codebase written in a language/framework/tech stack that is 10+ years old?
• Have we been struggling to hire Junior devs, seen a slide in motivation among our in-house folks, or even lost some engineers?
  • (read: why are there odd head-shaped indentations in the desks, and why is the entire dev team listening to Death Metal?)

TL;DR: ColdFusion is unappealing (to work with). So is VB.NET, Struts, and many other “legacy” platforms. While they may be supported, they don’t have a bright or clear future, and for your business to continue succeeding in the long term, you might consider the possibility of switching things up. P.S., especially if you want to still be able to hire and keep a team of software engineers.

If you’re nodding in agreement, you’re not alone. We’ve recently migrated three ColdFusion apps to PHP for an enterprise healthcare client; for another prospect, we’re discussing porting upward of 300 applications from ColdFusion to Node. We helped an educational institution strategize for, and then execute a migration from Struts to Spring, and have helped other clients move away from VB.NET to C#.

So what do ColdFusion, VB.NET, and Struts have in common? A deep seated disgust among developers, junior and senior alike. While this conundrum is not isolated, to these three platforms, by any means, they provide an easy example of the headache so many organizations find themselves in: their codebases are so often to blame. This translates directly into a lack of motivation on engineering teams working in such tech stacks, and when you’re not working on something that brings you joy, you’re neither productive, nor successful. Creativity drops, excitement falls away, heads are banged upon desks.

No matter how much padding you add to your desktops, no matter how much coffee is administered to your engineers intravenously, they’re not going to “come around.” You need to find a long term solution to this problem.

Just as senior software engineers who are well established in their careers cringe at the mention of decades’ old technologies, junior devs are determined not to touch them with a ten foot pole. Just getting started in their careers and with stars in their eyes, junior developers are anxious to move fast and break things, build out bleeding edge innovations, and be the hero of their sprints. They don’t, I repeat DO NOT, want to get stuck fixing backlogs of bugs, sifting through old, undocumented code, and trying to figure out what is going on in a legacy platform they don’t know or understand.

Ok, I’m not married to my old code, what’s the solution?

First things first, let’s clear something up. We do not recommend hard cutovers or overnight rewrites. One clear path forward is to remodel - to gradually and iteratively transform your codebase over time, until it is in a much better place.

At Corgibytes, our mission is to joyfully remodel software applications to be more stable, scalable, and secure. We absolutely love helping our clients reduce frustration in their operations by making their codebases healthier and easier to work with, which in turn, inspires makers (i.e. the majority of software engineers) to be willing to work on them. By exclusively focusing on existing (“legacy”) systems, we’re able to bring calm to the chaos.

Big rewrites and hard cutovers carry so much risk and are often much more expensive than a gradual transformation. For systems that are already delivering, and need to keep delivering value without downtime, it’s often a better strategy to think of software systems like your body. Every ten years or so nearly all of the cells are different, but at no point did your consciousness migrate in a hard cutoff from one corporeal form into another.

This is precisely the mindset and approach that we bring to projects of this sort, where a migration ends up being in the best interest of the organization, and their future team. For example, this can look like migrating VB.NET to C#, ColdFusion to PHP (or almost anything else), Struts to Spring, and many other examples.

The point is, your codebase is gradually and safely brought to a (more modern) state that is approachable for teams of varying expertise levels and tech stack knowledge. The good news becomes that there are far more engineers available on the market with these more modern tech stacks under their belts, who would jump at the chance to work for your already established, impressive organization, especially since the codebase itself isn’t such a hurdle to get over… get ready to interview!

Hold up, I love my ColdFusion/VB/Struts and just need to fix my staffing issue… help!

We get it! No really, we genuinely love legacy code! That’s why our founders coined the term mender when referring to software engineers that love fixing, maintaining, and improving - it takes all kinds to keep our software world going ‘round!

In fact, you’ll find that our team of expert menders are commonly in agreement with Joel Spolsky, when he writes in Things You Should Never Do: “The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they’ve been fixed. There’s nothing wrong with it.” We respect the decision to stick with your current platform, and are all for finding the beauty in older code.

If you are truly struggling to find junior (and more affordable) engineers looking to learn your tech stack and you’re determined to hang onto things the way they are for a few more years or so, you might need to consider bringing on a few more senior folks, with experience already working in those platforms. In the meantime, if you need expert engineers to collaborate with your team to maintain your systems and help you set a strategy for the future to come, Corgibytes is always glad to help out, and we’d love to be in touch!