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.

Psst... Don't tell anyone

[LynnwoodRooster]

But we're trying to move from C to Rust...

The schedule ain't gonna happen

[Snotnose]

Tallest nail gets hammered, keep my mouth shut hoping someone else takes the fall for being late. True story. Some 20 years ago I worked on Globalstar. The software was a good year late, we all knew it, but management a couple layers up didn't. They were launching a bunch of Globalstar satellites on a Russian rocket. There were 4 teams of us, all knew we were a year behind, sitting in a large conference room with a live link to the launch. Some 90 seconds in the rocket plowed into Russian real estate. We all looked at each other, breathed a sigh of relief, looked sad to our manager's managers, and went home knowing we were good with our 50 hour work weeks for another year.

Re:The schedule ain't gonna happen

[Anonymous Coward]

AKA Schedule Chicken. Though hoping the other team crashes and burns first is usually a metaphor...

https://en.wikipedia.org/wiki/Schedule_chicken

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.

Backdoor

[Anonymous Coward]

Our server has a backdoor letting you submit arbitrary code that gets compiled and executed. We use it to fix things directly in production since everything is a mess and things break all the time. You don't even need to log in, just hit the right URL and you are in. I can't understand how this hasn't been used by a disgruntled employee to delete the entire DB or something like that. By the way, this is not a worthless startup, it's a hundred million dollar revenue per year operation.

Already know the fix but I like to travel

[seoras]

As a young engineer in my first job I was the point man for a new technology in our company called ISDN.
Back in the early 90's each country had it's own flavour of ISDN for market protectionism or just to be different.
Our product started offering an ISDN interface as well as the other older comms interfaces (X25 etc).
I was at the "bored" stage with the dev work when a nice little bug started breaking things among our European customers.
I could have simply stuck a 3.5" floppy in the post (this is pre-internet) but since I'd never been to Switzerland, Munch (in Sept), Paris, etc, etc I was eager to travel.
What made this ruse even sweeter was that when I got on site I'd pretend to debug for a 1/2 hour, then switch floppy discs, and -hey presto- it all worked perfectly.
Each time I the toast of the office I was visiting, as well as our company sales team golden boy, rewarded by being taken out for a nice meal and drinks as a thank you.
If I'd just stuck the floppy in the post it just wouldn't have had the same effect nor would I have seen some nice parts of Europe or tasted their fine cuisine.

Re:Already know the fix but I like to travel

[Anonymous Coward]

I could do that install of our custom database base remotely, but, sometimes, I like to travel.

I need to be onsite to properly install the patch, but I don't want to miss my kid's birthday. I will "try all day" to install the patch remotely and discover sometime tomorrow that the customer "has a nonstandard configuration," which requires me to be at their site next week (not now).

BTW, for several years I spent about 60% of my time outside of my local city. I was given a generous expense account and put up in decent hotels. Each "day" on a client's site was an automatic 8 billable hours, plus time for pre- and post-visit memos. I did much of my coding on the plane. I always volunteered to "sacrifice" to make the trip so spare others that "hardship." My high billable hours was one factor in getting promoted. The previous person in that position had traveled very little, but the internet came along just in time. I was able to up my travel time to over 80% with corresponding benefits while managing the team through email and rudimentary document sharing. It also enabled me to avoid much of the office politics and bickering. I got to know the clients well (mainly by spending expense account money on them, or letting them spend theirs on me). When the inevitable periodic downsizing purges occurred, no one dared fire me because the clients would be upset.

I left that job to start my own company. My first client was my old bosses who wanted me to do basically what I was doing, but they paid me twice as much as my previous salary in consulting fees for doing even less work.

I am deeply appreciative of the opportunity. I got thrown into troubleshooting the most difficult problems, so, while I usually worked less, sometimes it was quite challenging which kept my skills sharp. I got a chance to see the world, and accrued lots of travel mileage and hotel points which I later used to take the family on vacations I could never have afforded otherwise .I had lots of down time in hotel rooms to study new coding languages, techniques, and time to build my own library of music and digital processing apps, some of which I still use today.

Re:Psst... Don't tell anyone

[flopsquad]

Dev: "Bless me Father, for I have sinned. I've been keeping terrible developer secrets. All our 'in-game footage' that supposedly shows off the new engine? Entirely pre-rendered."

Rev: "Go on."

Dev: "And I've been secretly coding everything in Rust, even though I promised the CTO I'd use a 'real man's language, like C.'"

Rev: "I see."

Dev: "And most of the day I'm not even coding. I'm posting on Slashdot and playing that mobile game from the Schwarzenegger commercials."

Rev: "Hmm."

Dev: "I lied on my resume; I said I worked for Google as a senior developer, but it was really a call center job with a company called 'Googe' that produces fake semen for German fetish parties."

Rev: "What sort of fucked up calls you must've... **AHEM** My child, these are grave sins to be sure, but anything can be forgiven by the generous mercy of --"

Dev: "I work on systemd in my spare time."

Rev: "I COMMAND THEE LEAVE, SATAN!"

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.