Ask Slashdot: What Are Some Developer Secrets That Could Sink Your Business?

snydeq writes: In today's tech world, the developer is king -- and we know it. But if you're letting us reign over your app dev strategy, you might be in for some surprises, thanks to what we aren't saying, writes an anonymous developer in a roundup of developer secrets that could sink the business. "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." What possible damaging programming dirt are you keeping the lid on? Some of the points the developer mentions in his/her report include: "Your technical debt is a lot bigger than you think," "We're infatuated with our own code," and "We'd rather build than maintain." If you can think of any others not mentioned in the report, we're all ears! This may be a good time to check the "Post Anonymously" box before you submit your comment.

Comments

The libraries we choose

[Shotgun]

We don't choose libraries and architectures necessarily because they are the best for your business. Sometimes, it is because they are hot in the market and we want professional experience to put on our resumes.

Oh, yeah. And we are keeping our resumes updated.

What a bunch of Bullocks

[Puff_Of_Hot_Air]

I note the "insightful" article is written by an anonymous author, as I wouldn't want my name tarnished with this steaming pile either. There is nothing of value here. Nothing. I note that "syndeq" simply spams articles from this CIO website, driving traffic there I suppose. Slashdot is a waste of time these days. I still come here out of habit, but it's a habit I need to kick.

When you lay off Joe, you doomed Joe's app

[Jeremi]

Remember the original Tron movie, where the software programs all looked just like the person who created them, except with neon duct tape on their clothes?

There's a lot of truth to that. The design of a piece of software will inevitably reflect the way its author thinks, his views about what the problem-space is and which techniques and engineering tradeoffs are appropriate, and the designer's own unique approach to problem-solving.

Moreover, the designer of the software is the person who has the most invested in that software's success, and thus the most motivation to keep its quality as high he is capable of -- other people may work on the codebase as well, but they are only step-parents, who may do a good enough job to keep things working (as far as customers can tell), but won't necessarily go the extra mile to make the software really shine, because hey, it's not their baby. To them, everything about the software looks like a bit of a mess, mainly because it wasn't implemented the way they would have done it. So why would they spend any more time on it than they have to?

So, when management decided to lay off Joe because they thought that with the app feature-complete they didn't need him anymore, they were unknowingly signing the death warrant for Joe's app at the same time. It won't die right away, since other programmers can come in, fix bugs, and add the occasional minor feature, but every time someone does that, the integrity and reliability of the codebase suffers a bit more, as the new developer's approach is different from Joe's approach, and thus the new code doesn't fit quite right with the old code. Eventually, development of the codebase slows to a near-halt, as the time, effort, and risk of making any further significant changes starts to outweigh the benefits that could be secured by making the changes. In another year or three, the app will be effectively dead, and the company will have to hire another Joe to write new software from scratch.

TL;DR: Programmers are not interchangeable parts.