9 developer secrets that could sink your business

Application development can be a key differentiator for your business, and the wizards who can whip up a market-leading mobile app or just the right custom code to make the business hum are well worth the investment. But the truth is, we developers aren’t always straight with you. We have a few secrets we like to keep for ourselves.

The fact that we don’t tell you everything is understandable. You’re the boss, after all. Do you tell your boss everything? If you’re the CEO, do you loop in the board on every decision? So don’t be so surprised when we do it.

Sometimes less knowledge on your part is more. You don’t need to know the directory where we stash the Java updates. Nor do you care about the password for the backups as long as they’re encrypted. You probably aren’t all that bothered if we switch to a different tool without asking every stakeholder’s approval.

[ Beware the 12 ‘best practices’ IT should avoid at all costs while heeding the 9 forces shaping the future of IT work. | Get an inside look at 10 real-world digital transformations. | Get the latest insights by signing up for our CIO daily newsletter. ]

But other things may make a difference. Other facts just might control the fate of the company and both of our paychecks. So in the interest of disclosure, here are nine things we aren’t telling you that could come back to haunt the business.

We have less of a clue than we lead you to believe

Developers are smart folks. And some of us are pure geniuses. But we do have a tendency to allow the impression that we know everything about those 1s and 0s get us over our heads at times.

Of course we know the foundations of programming backward and forward. We can write a loop or send a query to the database. And those foundations can get us far, even when we’re encountering a language, code base or development tool for the first time. But you’re rarely asking for the basics. You want us to fix a flow of functionality and we may be lucky if we know where all the code involved in that flow actually lives. And when we find it, fixing it could end up being easy or it might be hard. We won’t really know until we download the code, rewrite a few lines and see what happens. It’s not just scope creep that blows your timelines. It’s sometimes our inability to estimate the scope of the real work involved in the first place.

But who wants to say, “I don’t know?” at a meeting? Who wants to tell the boss that they don’t have a clue how to even begin or what tool will be best for the job? So we grab an estimate or a solution out of thin air and hope we’re right. And if we’re not, we’ll have to spin up some smart-sounding excuse like “the flux capacitor was overloaded” and get down to doing what we like least, reading the manual.

Your technical debt is a lot bigger than you think

When it comes to working on an existing application, management has a choice: Push the development team to make quick fixes or ask them to re-engineer the whole stack. Quick fixes often feel good — and appear to cost less. With a quick fix, you get to solve your problems immediately and we get to please you, which for the most part we like to do.

But over time the bandages and duct tape build up. Some smart developer coined the term “technical debt” to capture all the real work that should have been done but was delayed by a decision to use bailing wire and chewing gum.

Of course, it’s not an accurate term. You don’t need to pay the debt. If you’re lucky, you can keep the software running without reworking everything. But eventually some major event is going to break everything in a way that can’t be fixed easily. Usually it involves a close partner who finally upgrades to the latest version of some software package. Suddenly our code won’t run. Suddenly everything crashes and our code no longer interacts with our partner’s. Sometimes our partner will take pity on us and keep the old gateway running but that only works if we’re bringing our partner revenue. If we’re just a freeloader or a small account, the partner will kiss us good bye and there goes our business.

We’re bored — and looking at the door

The biggest problem for a business is retaining the smart developer who knows everything about your code but can’t stay interested in doing anything with it. This developer can knock out a fix or a feature enhancement ten times faster than the new kid who may be smart but doesn’t know anything about the code base. There are millions of reasons that leave us bored. Sometimes the code is written in a language that went out of fashion a few years ago. Sometimes we have bad memories of the hard work that went into building the code in the first place. Sometimes it’s all too easy to make the tables a bit wider or the background a bit bluer and we want a new challenge.

There’s not much you can do to alleviate the crushing boredom of plowing through the same code again and again. Letting developers rewrite it in the latest, greatest framework can help. As Ezra Pound said the poet’s job is to make it new again. Perhaps it’s the manager’s job as well. Or at least maybe it should be if you want to retain us.

We’re infatuated with our own code

Did you see that clever way I used the indexOf function? Just one line of code but it parses the cookie string completely. If you gave me another few days, I could have solved world hunger with that clever hack.

We’re in love with our own particular ways to program. We’ve settled into comfortable ruts and we love to deploy the same idioms again and again. You know the joke that every disease needs cutting when you go to a surgeon and that every task looks like a nail to a carpenter with a hammer? It’s like that for us, but with our own particular corners of the language. Functional languages? Object-oriented code? Assembly code? We’ve taken sides and we’re ready to deploy our favorite solutions — regardless of whether it makes sense for the company.

On the best of days, this isn’t a problem. Good developers don’t let their particular choices turn into dogma. And usually we’ve got good enough taste to fall in love with a pretty good idea. We should be flexible enough to recognize that many programming techniques are pretty much interchangeable. We should also be smart enough to recognize that there’s no perfect solution and every great feature or amazing hack comes with downsides.

But on the worst of days, we’ve got our muskets ready for civil war. Too many of us demonize and denigrate the developers who make different choices. Managers need to tread lightly but it can be confusing. It’s hard to know whether a technique is truly “braindead” or merely different when the programmers toss out harsh criticism so casually. And when you don’t know whether the developer pushing back is on to something or is simply being stubborn about their work, it can be difficult to make the optimal decision for the business.

We’re obsessed with the flavor of the month

Did you see the new open source project described on Slashdot? Did you see that article on InfoWorld? We absolutely need to pull down the code, compile it and integrate it with our stack. It’s going to make everything run so much faster. It will be sick. So much better than the slick new idea I wrote you about last month. That’s so yesterday. So last week. This is the real deal.

Progress is a big part of the tech industry. It’s generally a good thing that makes the machines better and better. All it takes is a visit to the Wayback Machine to recognize just how much everything has improved.

But developers often take this too far. We love to fall for new gimmicks and better code like a new car buyer falls for shiny things. It’s no coincidence that Google named its browser “Chrome.”

Reining in this instinct is a challenge. You don’t want to say “no” too often because our infatuation is often grounded in some practical need, if only to improve. But if we chase every new idea, we can lose track of what’s best for the business. Or worse, we can push a portion of the business over the cutting edge.

We’re often too lazy to advance the business

The only thing worse than chasing every new idea is not chasing any of them. There are too many developers who’ve grown so cynical that they don’t try to improve anything or research a new tool that could produce significant business results.

Yes, the new flavor of the month is going to be replaced soon. Yes, it’s often just a warmed-over version of something from a few years ago with some small improvements. Yes, the code we’ve got is running smoothly. Yes, it would be stupid to replace something that’s functioning with something else just because it’s new and improved. But if we ignore progress too often, we’ll wake up one day and realize we’re miles behind.

We often cloak this laziness with pride and some overly strong devotion to some technical detail. Did you know that Multics is pretty much the best operating system that’s much more secure than Windows? Or maybe Solaris is the best Unix ever? Or real BSD, not that wacky version from Apple that will never amount to anything because Mac users just want icons to click. We know the stuff we cut our teeth on is still the best.

This laziness is a close cousin of the Not-Invented-Here response that often slows progress. There are a lot of smart people on the internet, but somehow all the flashy ideas come from the dumb ones. If we didn’t think of it ourselves, it’s not worth doing.

The way to fight this is by indulging the one developer who gets ambitious occasionally. Even if the plan to deploy some new technology doesn’t make much business sense or promise to really change anything, it can be good just to get the blood pumping around the office. Shake things up a bit. After all, it’s just this kind of itch that could have your company making good on machine learning, the internet of things or whatever else comes next.

We’d rather build than maintain

One of the best teams I’ve met rewrites its app every single year. They spend the first three months rebuilding everything from scratch. Then they coast and by September they’re planning next year’s rewrite.

They are quite proud of their code, which is well-engineered, modular and usually built “the right way.” Their pride in their craft shows in their code. It’s not cobbled together. It’s solid.

But this approach is expensive, in time, money and emotional energy. The size of the team is bigger than one just devoted to bug fixes and maintenance. And they’re always thinking about whether something can be improved — which can get expensive and lead to burn out. Sometimes it’s best to build the stack and select a smaller set of the developers to stick out the maintenance, moving the rest to new teams on new projects — no matter what we say.

Not every app needs to be rewritten

Some of us like to get on our high horse about re-engineering and rebuilding things the “right way.” We’re not making this up. We’re usually correct about faults that can only be solved by a complete rewrite. Sometimes we’re 100 percent correct.

But just because it would be nice doesn’t mean it makes business sense. If 30-year-old Pascal or Cobol is doing the job, why mess with it? Are the new features going to add much to the bottom line? To make matters worse, nothing exists in a vacuum. Fixing X is going to disturb Y and Z, which depend on X. And those will trigger small errors in A, B, C and D. It’s like a chain reaction. No good deed will go unpunished.

Sometimes progress makes things worse. I remember one manager started pulling out his hair after giving into the fussy, buzzword-obsessed programmers who insisted that it was time to replace decades-old mainframe code that spit out uppercase letters on a green screen. The new code was buzzword-compliant with the latest, greatest open source libraries. The binary code was 1,000 times better than the old version. Yet it was also 10 times slower. I listened to one engineer defend the slowness because the new app “does so much more.” And by more, he meant animate TrueType fonts on a color background.

We don’t understand the business case

We may be super-smart about the world of databases, protocols and new programming languages, but most of us don’t understand much about why average people do what they do. And that means we’re not the best people to create a strategy for keeping customers happy and spending. We can keep the databases happy but we don’t have a clue what keeps customers coming back.

One good option is big data and successful metrics. These boil down transactions to numbers and numbers are what we understand. The real benefit of big data and artificial intelligence is that it creates a linguistic framework so business people on the front lines can communicate with the developers behind them.

Don’t be afraid to expand these metrics. Raw sales numbers are obvious. Look for squishier measurements like brand engagement and brand recognition. They’re not always perfect but they help us understand that appearance and emotional connections matter.

Related articles