• Smoke 003723 (google)

    Pandora's-Box-o-WTF™??

    Don't you mean a Codethulu?

    [[frist]]

  • Ollie Jones (unregistered)

    Reasoning with users? valuable.

    Giving them Visual Basic 6 and letting them do it themselves? fun! The best way to fight WTF is with WTF.

  • ray10k (unregistered)

    Nice little lesson on office politics. Here's to higher-ups with an actual spine, though! :beers:

  • IP Guru (unregistered)

    Sounds like an extension to my theory of Management Management, to get a manager to adopt a good idea 1st make then think they though of it.

    in this case applied to users (who have effectively been given Management rights)

  • Bradley (unregistered) in reply to Ollie Jones

    And be stuck maintaining it after it becomes "mission critical"? No thanks.

  • Anon (unregistered)

    The user will then talk to their nephew, who is "really good with computer stuff" and bring them in to privide the functionality in Microsoft Access. Fast forward 5 years and IT will need to take ownership of the tangled mess.

  • David (unregistered)

    Reasoning with users like that rarely works. In my experience it just means they complain that you're being unreasonably obstructive or padding things because you don't want to do any work. However, if you're 'just' a dev then you can ask the manager who always says yes which item has the highest priority, so then if they put this 'little' feature in front of more important things then when stuff slips you can point to that to show exactly who moved things down the priority list.

  • (nodebb)

    There is a very simple method, one sentence, to make them shut the fuck up:

    WHAT IS YOUR MANAGER'S BUDGET CODE?

    That should do it; but if the bugger persists, then:

    Because we are going to bill the originating department for all development requests.

    If you do not have your manager's budget code, you do not have his/her permission to book a request.

    Please leave my office now. Do not come back until you have the budget code.

  • I'm Okay With This (unregistered)

    Say what you will about Agile+Scrum/Kanban, but in my organization it has had a genuine impact on the ability for stakeholders to understand the gravity of their requests (and our ability to simply shut them down when needed).

  • Brian (unregistered)

    Reasoning with customers? That must be a nice world to live in. In my previous companies, it's always the managers and salespeople who make the wild promises and then expect the devs to pull a miracle out of their rear ends and implement this new feature while not sacrificing any other deadlines. And then when things inevitably crash and burn, guess whose fault it is? Most of the time, we never even talk to customers, much less have the chance to convince them that what they're asking for is a bad idea.

  • Andrew (unregistered)

    Those fields and dialogs exist where they do and like they do for a reason (perfected by the hand of God). Get mad and impose your design and will like a brutal dictator! It worked well for Steve.

  • RLB (unregistered)

    Two rules for trying to argue with lusers:

    1. The luser never knows what it really is, but expects you to deliver it to his precise desires;
    2. It is the most important thing in your business. No, this luser's it; any other luser's it is, obviously, less important.
  • Rob Hoffmann (google)

    This idea works well as long as none of your users are rampaging narcissists who believe that their (stupid) request is absolutely more important than the next full release, and will damn well go to the CIO or CEO to get what they want, at which point your explanation of how many man-hours are going to be wasted will come across sounding like the parents in a Peanuts TV show.

    Or you could work for a spineless CIO who caves to everyone. Hypothetically.

  • The Original Frits (unregistered)

    Oh yeah this approach works just great in IRL life I'm sure.

  • Hans (unregistered)

    You: Boss, should this feature be done?

    PHB: Yes, this is top priority!

    You: Then that previous top priority gets pused down?

    PHB: No, that is still top prio too.

    You: Should we then delay the next release until everything is done?

    PHB: No of course not. I promised next week, so next week it is!

  • Brad Wood (google)

    Where the wtf? I like the large stop sign, but where's my wtf?

  • (nodebb)

    Been there, done that.

    My last permanent job was at a place where I was hired to rewrite a massive VB6 application in C# using more up-to-date techniques such as asynchronous threading.

    I ended up leaving because my boss, who had written most of the original system, thought the new stuff was too difficult to maintain. It turns out what he really wanted was a code converter. The asynchronous stuff went away, to be replaced by the VB6 model of running everything in the UI thread. And let's not even get into the requirements that the application had to look and act exactly like the old application, which included all the weird stuff you could do with COM that .NET doesn't do anymore without tons of WinAPI calls.

  • (nodebb)

    Spot on, Snoofle. A good reminder of how important context is when making decisions.

  • DCL (unregistered)

    Another approach I've seen used back in the day, i.e. waterfall model on mainframes, was to put the user request(s) on a wish list for the next release. The wish list would then be reviewed some time later and fairly often the user reactions would include, amongst other things, "Who on earth requested that?" or "What was I thinking?" or "This has no business value".

  • (nodebb) in reply to Brian

    If you don't have direct customer contact, then employ the technique on whomever your liaison with the customer is. You show them how their requests affect the entire backlog, let them make the priority calls, then hold them to the decision.

  • Donald Knuth (unregistered)

    TRWTF is saying you pushed it forwards when you actually pushed it back.

  • ScienceGone_Bad (unregistered)

    Having been both a developer and a SysAdmin, I can say for sure that some of the same "This is how it's always been done" can live in development teams. At one job, the Powers on high stated that for security purposes, all rsh, telnet, ftp, etc. would be replaced by secure versions (SSH, SFTP, etc.) ... fine, the commands are nearly identical in their operation, and for the most part, putting 'S' in the command is all the fix needed.

    So I get the scripts ready to push out, visit all the affected teams, show them exactly what to do (basically grep-replace) explain to them that they can do the change now & have plenty of time to fix any weirdness, and leave.

    6 months go by and no change ... dev keeps saying that all of their old scripts will break, and they don't have time, and it's the way they've always done it ... the usual. The VP of the Company, who happened to have hired me, came by one day @ the end of work, and aske why the change hadn't been done. I explained everything, and said I'd been ready to push the change 15 minutes after we 1st talked. Also said I could do it right now as he watched, but I wanted one thing from him before.

    I wanted a signed letter from him & his boss stating that because nobody had even tried to transition the dev scripts, this change was effectively going to shut down the Dev department, and bring the business to a grinding halt (dev worked directly on prod a lot of the time). In the letter, I wanted it written, that I would not be the fall guy for this change when it went south.

    That change never happened during the entire time I worked there.

  • Alex Papadumbass (unregistered)

    If it were that easy, this site wouldn't exist. All that you are going to get in response is "you are the computer guy, so you make both things work right now" along with some escalations to the next level dumbass (aka PHB), "your computer guy is useless, he cannot add a button without delaying the whole schedule by 6 weeks". Good luck trying your oh-so-awesome trick with your dumbass PHB.

  • I Am A Robot (unregistered)

    Worked at one place where the salesdroid would do the usual thing of telling prospective customers that the application did ABC, then when the contract was signed we'd get top priority orders to implement ABC.

    Standard so far.

    Unfortunately all the existing customers would then get "upgraded" to the version with ABC in it, even it meant them losing the XYZ functionality they relied on, and there would then be a major inquiry as to why changing how a system works would result in changing how a system works.

    After than happening to me twice I took the time honoured WTF route and jumped ship.

  • eric bloedow (unregistered)

    i can't help but think of an older story: "what do you mean, it will take a month to add a button to the UI? my friend here added a button in fifteen minutes!" "and what does his button do when you click it?" "...nothing." "and that's why it only took him 15 minutes, getting it to actually do something takes a month!"

  • J. Random PMP (unregistered)

    You have essentially described a Project Manager's job.

  • Tash (unregistered)

    Wow! This is interesting. I am the dumb customer that you all write WTF scripts for and place on my laptops for your employers. I love this forum so I am snapping a photo. Now...this is a real WTF.

    WTF is CSX Corporation and Microsoft going to do when I sue the shit out of them? It is going to be a long ugly road to hell. Isn't there a road to hell script? Too funny...or not.

  • Harrow (unregistered) in reply to eric bloedow

    If it doesn't have to do anything then I can add a button in 30 seconds.

  • Barf4Eva (unregistered)

    "This is a good thing because it forces them down the rabbit hole into your world where you are the expert. Now you get to explain to them the realities of software development, and the full cost of their little request. "

    Yayyyy.... it's great.... I love doing that... explaining every frigging day why things work the way they work in order to try and curb bad requests from our users... :(

    Eventually, it becomes your NEW job when you relent to this suggestion...

  • (nodebb)

    This drives home the concept: "Everything has a cost". The sooner you explain it to everyone, the better off everyone will be.

    A a company I worked for, the sales guy would always be saying we got this big sale. I'd respond "Where is the check?". This usually shut him up pretty quickly. Of course, it helps if you are the entire software development team (it was back in the early 80's).

    Life goes on.....

  • Decius (unregistered) in reply to Harrow

    It would take about five minutes to add a button that adds a similar button. Rather than add the useless buttons manually, automate the process.

  • (nodebb)

    It goes the other way sometimes.

    I think I might have mentioned a large supplier of financial information services that I used to work for. I developed a good relationship with the sales / business development crew responsible for the same sub-product that I worked on, and we had a variety of responses:

    Salesguy: The customer would like to have X, but I'm not sure because it seems a pretty hard thing to do Steve: X? (thinks for a moment) No, that's pretty easy, because A, B, C.

    Salesguy: (Learning...) From what I've seen, Y shouldn't be too hard. Steve: Y? (thinks ... thinks ...) No, it's harder than you think because D, E, F.

    Despite a mild amount of technological ineptness(1), he learned quickly to distrust his initial feeling as to how much work things would take, and to just ask me. I think it was mostly because I took the time to explain why it wasn't the way he thought. And because I was careful to explain it in semi-technical terms rather than full-whack nerdspeak.

    (1) Like the time he called me at my desk and, getting distracted, put me on hold before I could answer, except I wasn't there, so it got bounced to my voice mail. As a result, I got a 20 minute recording of the company's radio station (which played instead of hold music) in my voice mail, and he was baffled as to why his phone wasn't working.

  • bobcat (unregistered)

    Another secret is to make it Not Your Fault, and to give options. "Yeah, I've talked with the guys. It turns out that implementing it that way will take us an extra couple weeks' worth of time, possibly a month. I know it's just a button, but it seems the existing code just isn't built for that sort of thing, and we'd have to rework a lot of it. We can give you this similar option in a week, or we can keep the existing format and add the whole thing on as a future update when we're not pressed for time."

  • (nodebb) in reply to eric bloedow

    "How much for these bananas?" "10 cents a pound." "10 cents a pound? The guy down the street is selling them for 6 cents a pound!" "So go buy them from the guy down the street." "He's sold out." "If I were out of bananas, I'd sell them for 6 cents a pound too!"

  • Really (unregistered)

    I wear a management hat for the software team in a startup that makes an IoT thing. Being a startup, that includes a lot of systems engineering type interactions with another engineering discipline. Director of engineering, who has a background that is not software, has criticized me for saying "no" a lot. I wear that badge proudly.

    I see similarities in this story to what happens here, and I appreciate it. DoE, and one of his other engineers in his discipline, make assumptions about how simple or not a request is, or even if it's possible, and are often wrong (surprise!). No matter how I approach saying No, they just don't like to hear it. I suspect they think it's possible for someone not actively working with a code base to get some sort of understanding of what's simple and what's not, or what might require an architecture change. Since they never seem to get it right, they think I'm calling them dumb, or something. I need to find a diplomatic way of getting across to them that, in software, everything is situational. Just because one thing in the past was easy and this new thing appears similar, it does not mean they'd take the same effort.

  • siciac (unregistered)

    When you have 700+ users and each of them wants a different dialog to do the same thing, and nobody in management will say no

    This kind of thing is why I always respected Steve Jobs for every extra port and button and sticker that Apple removed.

    (1) Like the time he called me at my desk and, getting distracted, put me on hold before I could answer, except I wasn't there, so it got bounced to my voice mail.

    That's not his technological ineptness, phones / voicemail / hold and all that stuff has been horribly broken for decades and telcos "fixed it" by telling customers it's their fault. We hold "ed" up as the standard for bad UX, but you dial through a PBX or internationally and you go through multiple states with nothing but maybe a clicking sound.

  • siciac (unregistered) in reply to David

    However, if you're 'just' a dev then you can ask the manager who always says yes which item has the highest priority, so then if they put this 'little' feature in front of more important things then when stuff slips you can point to that to show exactly who moved things down the priority list.

    The common idea of a yes-man is someone who sucks up, and that's one form. The other is worse: the guy who can't handle conflict and will always say yes, to everyone. He'll tell you, "yes, we will have to deprioritize this" and when you think you won that round he's still telling the customer, "yes, we can do this." Later you will get loads of grovelling apologies, but you'll still have to deliver on his promises.

  • (nodebb)

    I had one manager who had previously had a policy of developing the software, and releasing when it was ready. Then for some reason he decided to announce a release date and we were told there'd be a month before that, for (limited) user testing and another month before /that/ for in-house testing. So here's the date that we'd have everything completed by.

    The fact that we'd just discussed with him how much work was left to do, and the time it'd take, didn't seem to matter. So we just nodded and quickly found new jobs.

    My next manager had the annoying habit of listening to the MD. Who had great ideas, but my manager got too excited about them that he'd immediately start coding. Even in the middle of final testing. Then wonder why the software was broken and testing was overunning.

    We tried in vain to persuade him to say "Very nice, I'll put it in the upgrade path."

  • (nodebb)

    I had one manager who had previously had a policy of developing the software, and releasing when it was ready. Then for some reason he decided to announce a release date and we were told there'd be a month before that, for (limited) user testing and another month before /that/ for in-house testing. So here's the date that we'd have everything completed by.

    The fact that we'd just discussed with him how much work was left to do, and the time it'd take, didn't seem to matter. So we just nodded and quickly found new jobs.

    My next manager had the annoying habit of listening to the MD. Who had great ideas, but my manager got too excited about them that he'd immediately start coding. Even in the middle of final testing. Then wonder why the software was broken and testing was overunning.

    We tried in vain to persuade him to say "Very nice, I'll put it in the upgrade path."

  • Todas Elicti (unregistered)

    so...did you just figure this out or something? seems to be par for the course where i work...need to have a value proposition for work requests and things are done in priority order after being vetted.

  • Si (unregistered) in reply to Anon

    a million times this

  • b.a. freeman (unregistered) in reply to siciac

    when U're in a difficult political situation, document it; write a memo/text/email to the boss to confirm his decision, detailing everything that was decided. then, when he still makes stupid promises to the customer, it is documented that he told U otherwise, and it's on him (customers should do the same thing). even if the boss isn't willing to commit anything to permanent media, he can't stop U from doing it, and if he orders U not to document things, write an email documenting that and copy his boss.

    sometimes keeping a job working for a weasel is more detrimental than temporary unemployment.

  • (nodebb)

    What I say to people walking in and asking for just-a-little-change: "Quiet!" https://www.dropbox.com/s/2touqy1p2lrbf5d/Just%20Four%20Little%20Flagstones.m4v

  • tlhonmey (unregistered)

    This approach works up until you find yourself in an environment where the users just assume that your explanations of costs are a pack of lies and that you just don't want to do any work, backed by managers who assume that you can learn how to code anything in a couple of days, no matter how far outside your sphere of competence it may happen to be.

Leave a comment on “Yes == No”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article