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.

Re:The libraries we choose

[TheRaven64]

Uh, isn't that true of any native library? Most C and C++ libraries don't do anything you couldn't do yourself

You've selectively quoted him. The full complaint was:

many people use jQuery (which is a large CPU-heavy library) to do things that can be done in fewer lines of straight javascript

Why use a library and 10 lines of library calls to do something that you could do in 5 lines of code? You should use libraries when the cost of reimplementing the functionality is higher than the cost of using the library.

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.

Re: What a bunch of Bullocks

[KGIII]

I have been on /., for a long time. This is actually my second account, as I lost the email associated with the first one and forgot my password.

Why do I mention that? Slashdot has never been good. No, it really hasn't. That's kinda why I like it. Hell, we don't even get much goatse spam anymore.

I am on mobile, so search for 'VMware' on here. Go back and read the comments in the first article. Yup... We've never, ever, been good. If you don't want to search, the comments declared virtualization would never work, catch on, and that it was easier to dual boot. Keep in mind that these same people are the same people who submit articles to the firehose.

No, we've never been good.

Re:How are these "secrets"???

[MtHuurne]

I'd file the first two under "things managers don't want to hear" rather than "developer secrets":

Managers want to have estimates for their planning, so they pressure developers to make estimates based on sometimes very incomplete information. The best way I found of dealing with this is to make an estimate for the work of investigating how long the actual work will take and only add the actual work to the planning after that investigation has completed.

When it comes to technical debt, in my experience it is often the developer pressuring the manager to give them time to do something about it and the manager wanting to postpone it in favor of feature development. Some of that pressure is justifiable, as polishing code can be a huge time sink and doesn't always repay itself. But in my experience developers don't shy away from talking about technical debt.

When it comes to building vs maintaining, I don't think it's the case that every developer prefers to build. However, there are different people who do well at different stages of a project's life cycle: some people are good at building new software from scratch, others are good at adapting and improving existing software. Instead of rewriting a project every few years just to keep the builders happy, I'd suggest moving them to a new (sub)project.

The other "secrets" shouldn't be secrets to any manager who understands software development. Developers are people too: they like playing with shiny new toys, they have strong opinions (sometimes warranted, sometimes not) and they may not see the big picture since they're focused on their specialty.

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.

Re:Psst... Don't tell anyone

[TheRaven64]

This is exactly the sort of negativity which shows how the open source community is abusive and unable to cope when a great new idea comes along that throws away all those bad concepts in Unix, just because we're right and you're wrong.

Nonsense. Compare the reaction to systemd with the reaction to launchd (XNU) or SMF (Solaris). Most people who have had contact with either of the latter regard them as imperfect but significant improvements on what was there previously and, if they're using systems that don't ship with them wish that they did (or, ideally, something taking the good ideas from them each and combining them, leaving the bad ideas behind). No one is complaining about replacing traditional UNIX tools with something better, they're complaining about replacing stuff that mostly works with something that throws all of the last few decades of software engineering away.