URGENT: Need Immediately



  • I suspect our clients and our people overseas do not quite understand how software shops operate. The clients expect changes to be done immediately, and at the end of the chain of communication, I get these requests as either urgent or emergencies. Every day. Examples include requests for text, font, or color changes on our page. One moment the request could say "change this color to red" and the next day it would be "change this color to blue". It doesn't help that our site isn't architected... at all, so every small change could take hours to complete. Additionally, they tell me to make interface and functionality changes to features still in development. These features would sometimes not even be started, let alone prototyped.

    One weekend, management suddenly called me and said to deploy all development work to production because the feature was due immediately. So I deployed without any testing or any idea what was in our source repository other than the fact that it built. The following day they come back to me with 5 bugs telling me to fix it urgently, oh and 6 more changes to the interface and functionality.

    I also have a high priority project due soon, requested by the same client. I become aggressive to everyone I interact with since the change requests prevent me from even starting the project. I mention this problem to our team, but they don't know what to do since the clients are the ones demanding daily changes. I'm hearing all requests through the communication chain and not from the clients directly, so I'm not sure if the managers are useless or if the process of management is useless. Sadly, we cannot drop our clients since they bring us good money. Maybe experts like snoofle can spare some tips because I am getting desperate for ideas.



  •  Learn how to say 'No.'



  • @OhNoDevelopment said:

    Maybe experts like snoofle can spare some tips because I am getting desperate for ideas.
    I'm not smarter than anyone else (well maybe the morons I work with); it's just that I've been burned so many times over the years that I've learned how to make them eat their own stupidity.

    If you are a juggler, and your boss keeps tossing you more plates to juggle, you keep pushing your limits, straining to keep them all in the air. Eventually, you are tossed one more than you can handle. Do NOT just drop the one plate and keep the others going! Lose your rhythm and drop them ALL. The louder the bang, and the bigger the mess, the higher up the chain it will be noticed.

    If there is ANYONE with half a brain up the tree, they'll ask what happened and truly listen to your answer. This is the only hope of change in an arena like this. If they don't listen, then it's a black hole and you need to leave.

    Just make sure you've got an exit strategy (e.g.: another job) lined up as a backup - before - you let the disaster happen.



  • @OhNoDevelopment said:

    One moment the request could say "change this color to red" and the next day it would be "change this color to blue".
    Do you at least get all the requests via the same chain of communication?  Or could the request to change it to red actually be more current than the one to change it to blue, only it took longer to reach you?



  •  I don't take jobs where I can't communicate with the client.

    Development is a dance, a pas-de-deux, joining desire and technology. The client holds the desire, the programmer controls the technology. Each needs to adapt and react to the other. String a bunch of management morons in between who understand neither desire nor technology, and you're just begging to be burned.

     



  • @OhNoDevelopment said:

    One weekend, management suddenly called me and said to deploy all development work to production because the feature was due immediately.
     

    Did you get it in writing that they understood and agreed with the risks of early release without testing? I'd have drawn up a document stating what could potentially happen and require their dated siggies at the bottom so that people know who to blame is accountable when failure occurs.@OhNoDevelopment said:

    The following day they come back to me with 5 bugs telling me to fix it urgently, oh and 6 more changes to the interface and functionality.

    I used to get people to write those up on a whiteboard and request they cross off something to free up time for the higher-priority stuff (and initial it). When they begin to see how much you're juggling, it begins to raise awareness of failure potential.

    @OhNoDevelopment said:

    ... so I'm not sure if the managers are useless or if the process of management is useless.

    Both. Managers follow management processes (project management, risk management, change management etc) and if they don't see a failing of their own processes or can't follow them correctly... then they're not really productivity enablers. They're just muddying the water and don't really understand how much they're costing your organisation.



  • @snoofle said:

    Lose your rhythm and drop them ALL. The louder the bang, and the bigger the mess, the higher up the chain it will be noticed.
     

    That. Sadly, it takes a catastrophic failure for people to sit up and take notice.

    Minor WTFs can be smoothed over; it's difficult to conceal major ones. A post-mortem will reveal that there are issues to address to prevent recurrence.

     

    In my later years, I've began pushing back and refused to be "helpful" when dealing with minor WTFs that aren't part of my responsibility. I've learned that sucking it up and getting on with it means acceptance upon your part, and those that keep delivering those WTFs won't see any wrongdoing if you grip ankle and take it. Begin to show what effect management decisions are having upon your workflow, and let them know that they'll be held accountable for ramifications of their decisions.

    You can do that -  but you won't be to blame for following orders when the shitstorm happens.


  • :belt_onion:

    @Cassidy said:

    @OhNoDevelopment said:

    The following day they come back to me with 5 bugs telling me to fix it urgently, oh and 6 more changes to the interface and functionality.

    I used to get people to write those up on a whiteboard and request they cross off something to free up time for the higher-priority stuff (and initial it). When they begin to see how much you're juggling, it begins to raise awareness of failure potential.

    I've had this happen to me several times in the past. It always took me several months to re-educate the managers. For every so-called emergency request, I'd show them my taks list and asked them which of the other urgent items I could postpone or drop. Suddenly the new requirements weren't that urgent anymore.

     



  • Problems are not solved unless:

    1. they are both visible to those able to solve them, and,
    2. a motivation is provided to those able to solve them.

    It sounds as though neither condition is yet satisfied.

    You need to make the problem visible - whiteboards, post-its etc. showing the work waiting/in progress/delivered are often used. But you have to adapt to individual circumstances - "people overseas" and "management" can't see these through the phone. Maybe an internal webpage?

    You need to motivate solving the problem - which only happens when there is a cost to those causing the problems. Apparently deploying untested software doesn't cost them enough to motivate change, so it is hard to know how to make it matter.

    At the very least, if you organise things so that you can point to the list of outstanding work then you can say "this will cost you one of those". Or even have a rational discussion about which to do next.



  • @OhNoDevelopment said:


    One weekend, management suddenly called me and said to deploy all development work to production because the feature was due immediately. So I deployed without any testing or any idea what was in our source repository other than the fact that it built. The following day they come back to me with 5 bugs telling me to fix it urgently, oh and 6 more changes to the interface and functionality.

    Where I work, this request would get the relevant manager fired, and if I followed through on it, likely get me fired as well. It would also probably get our company fired from that client.

    My suggestion is to learn exactly how to say "go fuck yourself." If you can use those exact words, then great! More likely, though, you'll have to find a more diplomatic way to say it, like "Sure, just as soon as QA signs off on it."

    As I typed that, however, I realized that the chance of you having a proper QA department (or a QA guy) are approaching zero. In which case, god help you.



  • What everyone else said, and don't answer your phone on the weekends.



  • @OhNoDevelopment said:

    I'm hearing all requests through the communication chain and not from the clients directly, so I'm not sure if the managers are useless or if the process of management is useless.

     

    Well-well look. I already told you: I deal with the god damn customers so the engineers don't have to. I have people skills; I am good at dealing with people. Can't you understand that? What the hell is wrong with you people?



  • Hmm, never had these kind of problems before in our company, the process is pretty well defined.

    If the user wants a production change, they have to fill out a CRF (change request form) with the details (whether it be a bug, minor change or a new feature).



    We will then provide them an Impact Analysis document (simply a list of known affected programs and possibe module parts/logic that have to be rewritten, screens affected etc). Just as an FYI, but also in case they might have an issue with it.



    After that, we send an Effort Estimate document, which is just the same thing except with estimated manhours for each task, plus the task for the actual change added in. Including testing effort, since we have dedicated testers. Who HAVE to test EVERYTHING, even trivial changes like font color, since we've had experience of mundane stuff like extra 1px CSS border wrecking the layout when you use all characters in the maxlength of a certain field, etc.



    And also including overhead of generic things like build preparation, creation, deployment into production, etc. So they KNOW to keep their trivial changes together and not separately.



    They have to approve that effort estimate given, and not expect any results faster than the estimate.



    Then we bill them for the effort. Yep, for every little change.



    AND, after they've approved all these documents, they CANNOT demand for a change not outlined within, unless its a direct consequence, like an overlooked affected logic, and the effort has to be negligible. Otherwise they have to file another CRF for that.



    Yes, its tons of red tape, maybe even a wtf (?), but its great for protecting us devs from such impulsive client behavior.



  • @bundat said:

    Yes, its tons of red tape, maybe even a wtf (?), but its great for protecting us devs from such impulsive client behavior.
     

    You say it's tons of red tape. I say it's "doing it properly".

    And it works. Your honour, I submit as evidence:

    @bundat said:

    Hmm, never had these kind of problems before in our company



  • Yeah, the effort thing has the added effect of the manager knowing when you have your hands full, and not adding "more plates to juggle" into the mix.

    If they ask for a progress report, it can even be a one liner like, "today, 8manhours on task in cell 2B in the excel version of the effort est"

    We actually keep a copy of such an XLS in the CVS, updated by devs/testers everyday on manhours spent on each task, so that the project manager can know if we exceeded effort or went under it, and whether he has to look into "why" or not, etc.



    Which is sometimes bad when the project is under pressure, it turns "Dilbert-like", with effort inquiries everywhere, and even that odd "extra developer with no domain knowledge" thrown into the mix because the effort est just won't make the deadline no matter how you look at it.



  • @snoofle said:

    @OhNoDevelopment said:

    Maybe experts like snoofle can spare some tips because I am getting desperate for ideas.
    I'm not smarter than anyone else (well maybe the morons I work with); it's just that I've been burned so many times over the years that I've learned how to make them eat their own stupidity.

    Which is handy, since he's asking for wisdom instead of intelligence.



  • With clients like this, I've found the most helpful thing is to attach numbers to everything. If you can only attach hours, attach an industry standard developer hourly rate for your programming language. When you tell someone it'll take $300 to make that change, plus delay the real project x number of days (again, a concrete number helps here), their priorities start to change. This is also best to do before agreeing to make any changes, so they can't pin anything on you afterwards.



  • @da Doctah said:

    @OhNoDevelopment said:

    One moment the request could say "change this color to red" and the next day it would be "change this color to blue".
    Do you at least get all the requests via the same chain of communication?  Or could the request to change it to red actually be more current than the one to change it to blue, only it took longer to reach you?

    It all comes through the same chain of communication. I am all for the managers being the link between communication with the client because in theory they help take away the pain of prioritization and diplomacy. Here, I don't know what's going on since the managers are overseas.

    @Cassidy said:

    @OhNoDevelopment said:

    One weekend, management suddenly called me and said to deploy all development work to production because the feature was due immediately.
     

    Did you get it in writing that they understood and agreed with the risks of early release without testing? I'd have drawn up a document stating what could potentially happen and require their dated siggies at the bottom so that people know who to blame is accountable when failure occurs.@OhNoDevelopment said:

    The following day they come back to me with 5 bugs telling me to fix it urgently, oh and 6 more changes to the interface and functionality.

    I used to get people to write those up on a whiteboard and request they cross off something to free up time for the higher-priority stuff (and initial it). When they begin to see how much you're juggling, it begins to raise awareness of failure potential.

    @OhNoDevelopment said:

    ... so I'm not sure if the managers are useless or if the process of management is useless.

    Both. Managers follow management processes (project management, risk management, change management etc) and if they don't see a failing of their own processes or can't follow them correctly... then they're not really productivity enablers. They're just muddying the water and don't really understand how much they're costing your organisation.

    I kind of wish I did get it in writing from the client. At least then we would have something to redirect blame. I'm still in emergency mode dealing with the aftermath of deploying an unstable build

    Thanks for the replies everyone. Sounds like I got to start scheming a master plan of some sort to show them the cost of WTFery



  • @pkmnfrk said:

    @OhNoDevelopment said:


    One weekend, management suddenly called me and said to deploy all development work to production because the feature was due immediately. So I deployed without any testing or any idea what was in our source repository other than the fact that it built. The following day they come back to me with 5 bugs telling me to fix it urgently, oh and 6 more changes to the interface and functionality.

    Where I work, this request would get the relevant manager fired, and if I followed through on it, likely get me fired as well. It would also probably get our company fired from that client.

    My suggestion is to learn exactly how to say "go fuck yourself." If you can use those exact words, then great! More likely, though, you'll have to find a more diplomatic way to say it, like "Sure, just as soon as QA signs off on it."

    As I typed that, however, I realized that the chance of you having a proper QA department (or a QA guy) are approaching zero. In which case, god help you.

    0 QA. I guess I could be the QA because all responsible developers should test their own code?



  • Sounds horrid.

    Even the part where you have to "deploy unfinished code to production" sounds to me like there is NO formal process enforced at all.



    Better move to somewhere where there are processes at each step (e.g. each enhancement in a separate branch in source control, QA/testers must confirm the enhancement before passing it up to user acceptance testing (uat) (fully documented with a paper trail), which is required before deploying to production, so that they can't complain, and only then can you merge the branch).



    Heck, nowadays I even think that dedicated testers/QA is mandatory to maintain a non-stressful dev working environment.


  • Discourse touched me in a no-no place

    @OhNoDevelopment said:

    I guess I could be the QA because all responsible developers should test their own code?
    A developer testing their own code is not QA. Yes, it should be done, but that doesn't make it QA.



    Even another developer (uninvolved with the change concerned) doing (more) testing would be better than just the original developer doing their own testing.



  • @OhNoDevelopment said:

    I guess I could be the QA because all responsible developers should test their own code?
     

    You are performing QA by testing, but QA shouldn't just be confined to "developer had tested and it works".

    Full QA should involve all stakeholders to provide testing at different levels (integration, systems, user acceptance) - as well as different levels of independence.

    or: as PJH said.


  • :belt_onion:

    @OhNoDevelopment said:

    I kind of wish I did get it in writing from the client. At least then we would have something to redirect blame.
    That's not so hard. Send out a mail: "As per conversation with xyz on dd-mm-yyyy, xyz added a new requirement for client abc: ...(description goes here)... Can you please confirm my description is accurate? I believe this will take n mandays and have this or that impact on project schedule. Don't hesitate to send me any remarks if you think I've missed something.".



  • @OhNoDevelopment said:

    0 QA. I guess I could be the QA because all responsible developers should test their own code?

    Aaaaaahhh!

    No, you are not QA. Trust me on this, no one is capable of testing their own code. It's not possible. I don't know why this is the case (I imagine it's some psychological thing), but you absolutely need someone to test it before you can even consider deploying it to production.

    Don't get me wrong, you should always test your code. Unit testing, manual testing, trying to poke at the boundary conditions, all that jazz. Code exists in a quantum state; if you skip testing, it will be horribly broken and mangled the moment it leaves your box. On the other hand, if you test it manually... well, it will still be broken, but at least it will compile.

    Now, all that said, what is really important is your boss's (boss's boss's etc) perception of QA. If you are producing software for internal use (eg, not for a client and not for general distribution), then it may be seen as a wasted expense to have anyone doing QA. However, this is a fallacy. If this is an application that your company uses to conduct business, then they can't afford [i]not[/i] to test it. What if there's a bug in the billing code that over or under bills? What if the sales site is down and your reps are without their materials? Etc.

    If, on the other hand, you are working for a client, then your shop is pure insanity and you should leave as soon as possible. I would be downright embarrassed to work for a company that did not respect their clients enough to test the code they were selling. Never mind the legal implications, etc.



  • @pkmnfrk said:

    what is really important is your boss's (boss's boss's etc) perception of QA.
     

    That.

    If you don't QA a product, then you're not bothered by the quality of the product. Or, more simply put - if you don't test it, you don't mind when it fails in production.

    Testing doesn't prove it works, it proves it fails (under the right circumstances).

    Developers submit code in the belief it works; testers accept it in the belief it doesn't. A tester is simply trying to expose as many failures before the product is put to live use. 

    All products inherently contain defects.  It is cheaper for a tester to detect those defects than for a customer to experience failures caused by those defects.



  • My rules of thumb when give 'high priority' or 'emergency' or 'critical' things to work on:

    • If it is the only high, emergency or critical around and it is clear they are properly using the term, treat it as such other wise:
    • I only work on an item if I get told more than once it needs to be worked (and both times must be within a week of each other) otherwise it is not that imporant
    • If the customer tends to change their mind on a particular item (like font color), dont do it and wait for them to change their minds again.  (Generally I try to avoid working on things that are just going to change it is a waste of energy). Wally has used this to his advantage by 'working' on programs that get cancelled and claiming all his hard work was wasted.
    • Deadlines are relative. 

    Also if your customer is not full of total idiots and there is one person in management that has a brain that you can interact with, get that manager to teach and train the customer in proper severity scaling and customer conduct.  Bonus points if that manager can get the customer completely tied up in so many meetings that they do not have time to complain about things.



  • @pkmnfrk said:

    @OhNoDevelopment said:

    0 QA. I guess I could be the QA because all responsible developers should test their own code?

    Aaaaaahhh!

    No, you are not QA. Trust me on this, no one is capable of testing their own code. It's not possible. I don't know why this is the case (I imagine it's some psychological thing), but you absolutely need someone to test it before you can even consider deploying it to production.

    Oops, I meant that to be a sarcastic joke with the question mark and all.

    @Anketam said:

    My rules of thumb when give 'high priority' or 'emergency' or 'critical' things to work on:

    • If it is the only high, emergency or critical around and it is clear they are properly using the term, treat it as such other wise:
    • I only work on an item if I get told more than once it needs to be worked (and both times must be within a week of each other) otherwise it is not that imporant
    • If the customer tends to change their mind on a particular item (like font color), dont do it and wait for them to change their minds again.  (Generally I try to avoid working on things that are just going to change it is a waste of energy). Wally has used this to his advantage by 'working' on programs that get cancelled and claiming all his hard work was wasted.
    • Deadlines are relative. 

    Also if your customer is not full of total idiots and there is one person in management that has a brain that you can interact with, get that manager to teach and train the customer in proper severity scaling and customer conduct.  Bonus points if that manager can get the customer completely tied up in so many meetings that they do not have time to complain about things.

    I tend to give the benefit of the doubt when someone screams 'emergency'. I usually don't have enough context to judge if things are emergencies so I just oblige. Slowly things are getting clearer that they are like kids wanting everything in the moment. It doesn't help that the clients are big-headed because of the whole "you need us but we don't need you" situation. It feels like everything is backwards at my company: project managers and clients overseas. Have you ever seen a backwards inheritance tree? It's... ingenious ...to say the least



  • @OhNoDevelopment said:

    Have you ever seen a backwards inheritance tree? It's... ingenious ...to say the least.

    [url=http://forums.thedailywtf.com/forums/p/18854/229913.aspx#229913]Yes.[/url]



  • @pkmnfrk said:

    …no one is capable of testing their own code. It's not possible. I don't know why this is the case (I imagine it's some psychological thing)

    It is absolutely psychological. Our code is our own creation. We generally think we are perfect and that we create perfect things. Finding an error in our creation would imply we are not perfect, so our brains refuse to accept errors in our creations. Program code must be tested by a third party (someone with no vested interest in the code).

    Now, some advice for the OP: Learn how to write CBA (cost-benefit analysis) documents if you don't alreadty and start providing them in response to work requests before you do any work. For example, if an "urgent" request for change X comes through the chain then respond with "doing change X will cost $A and will also delay work requests M, N and O at a cost of $B, please confirm the cost $A+B is acceptable for this change before work commences". This does, of course, have to be supported by you and your team managers and your sales representatives - in other words, it needs "management buy-in".

    Additionally, consider ITIL or MOF or similar training.



  • @pkmnfrk said:

    Trust me on this, no one is capable of testing their own code. It's not possible. I don't know why this is the case (I imagine it's some psychological thing)
     

    Pure bollocks.

    @pkmnfrk said:

    but you absolutely need someone to test it before you can even consider deploying it to production.

    That's because you might miss a few obvious things, not because of some kind of subconscious psychiatric flaw in our mental core.

     

     



  • @havokk said:

    It is absolutely psychological. Our code is our own creation. We generally think we are perfect and that we create perfect things. Finding an error in our creation would imply we are not perfect, so our brains refuse to accept errors in our creations.
     

    I've never met a programmer who did this. We call these people "dicks".

    @havokk said:

    rogram code must be tested by a third party (someone with no vested interest in the code).

    This, of course, for reasons outlined above.

     


  • ♿ (Parody)

    @havokk said:

    @pkmnfrk said:
    …no one is capable of testing their own code. It's not possible. I don't know why this is the case (I imagine it's some psychological thing)

    It is absolutely psychological. Our code is our own creation. We generally think we are perfect and that we create perfect things. Finding an error in our creation would imply we are not perfect, so our brains refuse to accept errors in our creations.
    Program code must be tested by a third party (someone with no vested interest in the code).

    I agree that it's psychological, but the bigger problem isn't the ego issue, but all of your preconceived notions going in. It's like proof reading your own writing. You know what you meant to say, and you often fill in the blanks when you re-read what you wrote. But someone coming to the text fresh doesn't have any of that baggage and can more easily spot errors. Users always find novel ways to use your code that never occurred to you.



  • @dhromed said:

    @pkmnfrk said:

    Trust me on this, no one is capable of testing their own code. It's not possible. I don't know why this is the case (I imagine it's some psychological thing)
     

    Pure bollocks.

    Which part? "You can't test your own code" or "it's psychological"? Note that that doesn't mean that humans have some kind of crazy brain disease that causes our eyes to render text differently depending on how long it's been since we wrote it. But, well,

    @boomzilla said:

    I agree that it's psychological, but the bigger problem isn't the ego issue, but all of your preconceived notions going in. It's like proof reading your own writing. You know what you meant to say, and you often fill in the blanks when you re-read what you wrote. But someone coming to the text fresh doesn't have any of that baggage and can more easily spot errors. Users always find novel ways to use your code that never occurred to you.

    That.



  • @pkmnfrk said:

    Which part? "You can't test your own code"
     

    That bit I know is bollocks.  There's nothing preventing developers from testing their own code.

    If you meant that the quality of tests performed/designed by the code author isn't likely to be as high sa independent testers, then yes. But to say flat outright that "you can't test your own code" is hairy sphericals, I'm afraid.


  • Considered Harmful

    @Cassidy said:

    @pkmnfrk said:

    Which part? "You can't test your own code"
     

    That bit I know is bollocks.  There's nothing preventing developers from testing their own code.

    If you meant that the quality of tests performed/designed by the code author isn't likely to be as high sa independent testers, then yes. But to say flat outright that "you can't test your own code" is hairy sphericals, I'm afraid.

    Here: "it is certainly possible to test your own code, however it is highly improbable that you will find every defect that an impartial tester would be able to identify." This owes mostly to the fact that you as the developer know the intended workflow, and cannot predict how other users might interpret and interact with the user interface. Fór áll yóu knów théy míght stárt typíng cháráctérs yóúr kéybóárd dóésn't hávé, using accessibility features you've never needed, are running at 640x480 resolution (or 6400x4800), use a high-contrast color scheme, or a million other factors that a developer may not have even considered.

    Yes, you can test your own code, but you're not going to do a good job.



  • @joe.edwards said:

    Here: "it is certainly possible to test your own code, however it is highly improbable that you will find every defect that an impartial tester would be able to identify." This owes mostly to the fact that you as the developer know the intended workflow, and cannot predict how other users might interpret and interact with the user interface. Fór áll yóu knów théy míght stárt typíng cháráctérs yóúr kéybóárd dóésn't hávé, using accessibility features you've never needed, are running at 640x480 resolution (or 6400x4800), use a high-contrast color scheme, or a million other factors that a developer may not have even considered.

    Yes, you can test your own code, but you're not going to do a good job.

    I think you stopped reading after the second sentence. Here, I'll quote it for you:@Cassidy said:
    If you meant that the quality of tests performed/designed by the code author isn't likely to be as high sa independent testers, then yes.


  • Considered Harmful

    Then I agreed with you. I'm not sure why you would call something bollocks and then undermine yourself in the next breath. If anything, I was trying to reiterate that the difference is great enough as to render developer testing worthless as a metric for determining production readiness. (In this sense, no, you actually can't test your own code [worth a damn]).

    I guess, to rephrase, if the only testing that gets done is by developers, then I pity your application's users.



  • @joe.edwards said:

    Then I agreed with you.
     

    You did.

    @joe.edwards said:

    I'm not sure why you would call something bollocks
     

    Because I believe the statement "You can't test your own code" is untrue.

    @joe.edwards said:

    and then undermine yourself in the next breath.

    I didn't.

    I simply conceeded that your own testing may not be as effective as independent testing, but that doesn't imply "You can't test your own code" is a true statement


Log in to reply