Developer Repellent: Scenarios That Make Us Squeamish

That sinking feeling. The thousand yard stare.

Ever have a to-do that just doesn’t want to get done? No matter how important it is, any excuse is good enough to put it off a little longer? I really need to clean my gutters, but my limbs decide they’re made of lead whenever I try.

Software development is full of ‘em. And, instead of being code-related, the root issue is usually communication — process, paths to avoid, business decisions, pitting the present against the future — concerns like that. Important topics that need a resolution, but are tougher to resolve.

To avoid avoiding these tasks, here are some worth looking out for:

We’ll Skip the Routine Project Woes

There are plenty of big, obvious, waving development red flags, like:

• A lack of automated tests, or (haunted-house-esque) abandoned tests.
• Everyone’s favorite phrase: “The old code is the documentation.”
• A large migration of old, thorny data.
• Managing a mess of dependencies, the second most common developer topic in our company chat. (Don’t worry, the first will pop up later.)

They’re worth a mention, but fall into well-tread territory. We’ll focus on a few scenarios that sound a little more harmless.

Coding Without Constraints

The budget’s fuzzy, the timeline’s a shrug, and the tech stack can be whatever. Seems like a dream setting for a developer to build the perfect application (or, at least, the one they want).

If limits are a box, software will always fill the box. If there’s no box, time and cost like to spiral into something everyone will regret later. It may seem counterintuitive, but setting limits — even when they’re not “real” — gives a team the agency needed to make decisions. Gotta have a box to think outside of it.

Custom Code On Top of Nested Dependencies

Frameworks, libraries, and services (open-source or paid) are the backbone of web applications: WordPress, Shopify, Next.js, and the like. They handle the hard, recurring problems, and it’s usually an uphill struggle to argue against using one.

The issues crop up when it’s time to add functionality. Maybe a major feature is added through a plugin. Maybe that plugin doesn’t quite do everything, and there’s another plugin that gets you closer. Perhaps, to make the experience perfect, some custom code needs to integrate with that second plugin.

This is where a developer’s eyes start watering. Issues abound:

• Updates to the second plugin may break the custom code.
• Also: Updates to the first plugin may break the second, the custom code, or both.
• And: Updates to the underlying service may break all three.

Stacking dependencies can’t always be avoided, but should be a calculated risk.

Big Third-Party Integration, Tiny Feature

Salesforce is really powerful. If you’re only using it to store email addresses, though, it’s like taking a private jet across town. Big integrations — including initialisms like CRM, CMS, and ERP — come with a learning curve, performance questions, and (potentially) significant setup time. It’s hard to shake the overkill feeling if the need is marginal.

Do you really need a content management system if the content will only see minor tweaks this year? Should we toss a fully-fledged blog in if it’s only for quarterly press releases? That sinking feeling is back, especially if budgets or timelines are tight.

The caveat, of course, comes down to the roadmap. If there’s a real need, plan, and set of deadlines for leaning into the integration further, the effort is easier to justify.

Rebuild the Exact App, But Better

Modernizing a really old application (10+ years) is a tough task. There’s a common set of directions:

• The new version still needs to do everything the current app does.
• But it’d be great if it did some things better.
• Here’s a list of new feature requests that couldn’t be added before.
• Don’t change these parts, though — we’ve always done it that way.

Achieving parity with an old system’s features is a delicate operation. It’s always sporting outdated code, “temporary” patches, years and years of one-off tweaks, logic that no one quite remembers, and more decisions than can be reasonably unraveled. Recreating the same platform is like trying to recreate a junk drawer.

At the same time, new brings tension. The industry has matured, our ideas of user experience have changed, and the patterns, frameworks, and services (and competitors) available may point to a re-think instead of a rebuild.

A replica with modern tools isn’t the time-saver it sounds like, and developers really, really want to toss or change the one-off, hyper-specific segments of code. Consider a strategy step.

Critique the Developers Who Came Before

We don’t have the context needed to pass judgment on former developers. Being critical with the benefit of hindsight is disingenuous.

A sloppy feature could be the result of an unrealistic timeline. A sketchy security choice might’ve been made while the app was an offline-only prototype. These things shouldn’t see production, but fault is a hard thing to assign.

When asked to review existing development efforts, we’ll preface most statements with “based on what we know” or “if we were starting this fresh.” The aim should be evaluating the quality of the product against goals — not the journey or the people who made it.

Find the Perfect Third-Party Provider

Third-party services have come up a few times already; here, we’ll talk about actually picking one. If you’re looking for a CRM, how do you choose between Salesforce, HubSpot, Monday, Zoho, or the dozens of other options out there?

Features, offerings, and costs tend to be cryptic for big SaaS platforms. Making heads and tails of it all feels degree-worthy.

Weighing big third parties (the mission-critical stuff) is a research project. There are sales calls to sit on, developer documentation to review, and plenty of conversations to be had. The decision is as much business as it is technical, so the choice is something the team has to own — every platform has pros and cons, and the cons should be an accepted (or mitigated) reality to avoid finger-pointing.

Sort Out Authentication and Credentials

I mentioned our company chat’s second most common topic already (managing a mess of dependencies). The first? Passwords and other means of authentication.

Companies tend to start on one extreme end of the security spectrum or the other. For those that’ve been a bit cavalier with credentials so far, it’s a tricky shift:

• No more sharing passwords via email and chat
• Passwords are strong, unique, and managed
• Access to systems like servers is carefully controlled
• Account sharing is limited at best

Without a responsible approach to security in place, the rest of a project is really for naught. It’s the first thing to sort out, and, while it may feel a little too suit-and-tie for some startups, getting credentials under control is non-negotiable.

Past the management of secrets, there’s a whole host of new, related conversations: Should single-sign on be supported? Signing in via other third-party accounts like Google? Multi-factor authentication? Other means, like magic links and passkeys?

To-dos With That Sinking Feeling

The common thread? A common topic: communication.

Developers’ technical expertise only goes so far. Implementation will also run up against business decisions — and the reality that many choices can’t be perfect.

To avoid the wallowing and procrastination that can accompany the selection process, keep an eye out for these scenarios, keep context close at hand, and have stakeholders stay part of the process.