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

[Anonymous Coward]

And sometimes those "hot" libraries will sink your business because they're not mature, and sometimes those libraries are just a wrapper over a another library, and the "new" library is nothing but a package of the previous library.

Take for instance Javascript and jQuery. There is nothing that jQuery does that native Javascript doesn't do, however 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 load this enormous library just do do that damn letterbox effect that takes 8 lines.

One needs to make sure they need most of the tools in the library toolbox before they can justify using it, and sometimes it may be better off going to the what that library pulls in.

Take libRetro. All these pirate emulator devices use it. Don't use it. Because the libraries of emulators it use are not only out of date, but frequently incorrectly licensed. If you need a SNES emulator to re-release your 1994 game under Steam (Hello Bubsy) you might actually be releasing a version that is worse than the original because the emulator quality is bad. There's a recent bug (last 4 weeks) that was discovered in all emulators. Too bad many emulators forked from Higan/BSNES and SNES9X and other developers are so old that these patches will never reach them.

This is just an example of a recent thing.

Re:The libraries we choose

[Anonymous Coward]

Take for instance Javascript and jQuery. . There is nothing that jQuery does that native Javascript doesn't do,...

Uh, isn't that true of any native library? Most C and C++ libraries don't do anything you couldn't do yourself... but the point is they did it already so you don't have to reinvent the wheel. The point of a library isn't to necessarily do something you couldn't do before, but to help you save development time (which can also include getting higher performance in some cases than someone who isn't as experienced at optimization).

The rest of that sentence after what was quoted just amounts to complaining people use the wrong tool sometimes and that is true regardless of whether the tool came from a library or something they spun themselves.

One needs to make sure they need most of the tools in the library toolbox before they can justify using it,

This really depends on your constrains and even what language you're using. Plenty of languages will load or pull in only what you use, so it doesn't matter how much stuff there is you don't use. Even if it pulls in a lot of cruft, there are projects where the load time and/or memory usage is nowhere near the main constraint on costs or lack of benefits. There is nothing magical about getting more benefits from using more than half a library, it comes down to the value of what you do use verse the cost of doing things that way.

Re: The libraries we choose

[davester666]

What about "If I told you, then you would replace me with a cheap Indian programmer."

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.

Re:The libraries we choose

[bluefoxlucid]

While jQuery is kind of crap, you'll have a hard time explaining why.

A lot of things done right are done with more code, not less. Instrumentation and framework, encapsulation, things that make your program maintainable and segment it into logical pieces all have some programmatic overhead. Only an immature programmer would pre-optimize by throwing away the maintainability of the codebase to save a few lines of code.

We put everything in AWS

[Anonymous Coward]

Once upon a time everything was in a colo facility. Then they decided to rewrite the application we use to do everything. They put it in AWS. All of it. They they spent several man-years writing a bunch of automation between the various modular bits using Amazon's APIs.

Imagine the surprise from the beancounters when the thing they deployed took way longer than they said it would, cost a lot more than estimated, and has more than 3 times the opex costs compared to what we used to pay for hosting it ourselves, and now it's in AWS with no way to get it out without breaking all the automation that so much time was invested in writing.

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:Build rather than maintain

[Anonymous Coward]

Frank was a hell of a contributor. Until his daughter drowned. Then he was a worthless pile of crap. I hate to say it, but his goal in life was to use a shovel to fill in that swimming pool. Know what? The 3 of us carried him. Frank did maybe 1/3 of his workload, the other 3 of us covered for him. Our immediate boss knew what was going on, and also knew Frank was a damned good engineer.. This went on for a good year, then 2 things happened. First, he filled that pool and started turning into a good engineer again.

The message I'm receiving here is Frank needed time off for family leave, your worthless fucking company wouldn't give it, your worthless fucking country didn't have any kind of social safety net to allow Frank to quit so he could grieve properly, and you worthless excuse for a person won't even acknowledge these things. Your society is shit, and you are shit. Fuck you.

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.