Discussions with your boss


  • Grade A Premium Asshole

    I think you missed the entire point of his post.


  • 🚽 Regular

    [Quote]If the CTO can see your "refactoring errors" from nowhere near your desk, you're doing something wrong.[/quote]

    He was right next to my desk. Read the freaken OP.


  • Grade A Premium Asshole

    ...and came over to talk about other random shit.


  • Garbage Person

    @blakeyrat said:

    For example, your using statements should be inside the namespace, not outside the namespace.
    ... You can do that? I had no idea.


  • Garbage Person

    This morning I had a discussion that amounted to:
    PM: We need to do niche industry file format x.
    Me: OK. So install the niche industry file format x module on the production hardware and it's done. The vendors support it.
    Boss: No, we need to convert it to mainline industry file format y!
    Me: Uh, well, let me do some research on vendor offerings.
    PM: How will you validate that niche industry file format x are being reproduced correctly in mainline industry file format y?
    Me: We don't. That's why we pay vendors to do it.
    Boss: We need to do it.
    Me: We are not going to QA third party software. <Googling in background>
    Boss: Why are we using third party software? Can't we just implement the parts of the [open] specification that this customer uses?
    Me: Because if we did, one salesman would say to another "we support niche industry file format x!" and we're immediately on the hook for the entire spec.
    Boss: If we tell them that it's only a specific...
    Me: NO! Anyway, no third party vendors support converting to mainline industry file format y. In fact, the only certified implementations are the production hardware vendors.
    Boss: OK so we have to convert it to mainline industry file format y ourselves.
    Me: <sigh>
    PM: Oh, how are you going to do <file format feature z>?
    Me: Can't. Mainline industry file format y doesn't support that at all.
    Boss: So we have to convert it to mainline 1980's industry file format v instead.
    Me: How about we update our fucking production equipment software more than once every twenty years? Then we'd support formats v, y, x, l, m, n, o, p, q, r and s out of the box.


    Mod: PJH - htmlencode("<"); // unhiding parts of the text



  • @Weng said:

    Me: How about we update our fucking production equipment software more than once every twenty years? Then we'd support formats v, y, x, l, m, n, o, p, q, r and s out of the box.

    @Weng said:

    Me: NO! Anyway, no third party vendors support converting to mainline industry file format y. In fact, the only certified implementations are the production hardware vendors.

    It seems like it shouldn't be an issue since your hardware can't consume mainline industry file format y anyway. CLOSED WONTFIX



  • @NedFodder said:

    Boss: Project X is your #1 priority, don't work on anything but Project X.
    Me: But yesterday, you told me "Project Y is your #1 priority, don't work on anything but Project Y." Which one should I work on first?

    Pretty much continual here. I just get stuff done as and when I can.



  • @CoyneTheDup said:

    Boss: When can you finish project X?
    Me [doing a quick calculation based on 640 hour estimate]: I should be able to have it done by May 1.
    Boss: What about if I assign another resource to the project?
    Me: Well, then, we should be able to finish by March 1.
    Boss: What about if I assign two additional resources to the project?
    Me: Well, then it should be done by February 10th or so.
    Boss: Great! Let's get going.

    That's how you'd like it to work. In reality, it should go something like this:

    Boss: When can you finish project X?
    Me [doing a quick calculation based on 640 hour estimate]: I should be able to have it done by May 1.
    Boss: What about if I assign another resource to the project?
    Me: Well, then, we should be able to finish by August 1.
    Boss: What about if I assign two additional resources to the project?
    Me: Well, then it can never be done.
    Boss: In that case the project is cancelled. But start work on it right away anyway.



  • I love the concept of pay-to-lose games and would like to subscribe to your newsletter.



  • Recently, I've had reasonable line managers that understand the intricacies of estimating these kinds of things. What really grinded my gears was how the Sales Managers would try to tweak the questions for your estimates to lower the time spent quoted to the client.

    Sales Manager: How long will it take?
    Me: 2 months. Planning, build, testing, deployments, the works.
    Sales Manager: And just build, how long will that take?
    Me: A month.

    Then sales manager turns around and promises the client a production deployment within a month of go-ahead 😡



  • Technically not my boss, but QA/client contact, but still.

    Situation: there are two versions of the software - let's name them version A (which the client has on production, and we have on the support environment), and version B (which has just finished UATs at the client's, is still on our test environment, and is due to be moved to prod ASAP). There are still a few change requests that haven't made it to version B, but we want to avoid working on version C before rollout, since every branch we need to support is a PITA requiring a separate DB, QA environment, et al.

    Me: "Okay, I can start working on that change request, but I'd rather they rolled out the release before I go ahead checking in code".
    QA: "Well, the release is scheduled by the end of the week, but I'm not sure we'll be doing it".
    Me: "Why? As far as I know, they're done with UATs?"
    QA: "Yes, and... they don't like it".
    Me: "What do you mean 'they don't like it'? They filed a single bug, which was their IT fucking up permissions, I've heard nothing else from them, so what is it they don't like?"
    QA: "I don't know. They just don't like it".
    Me: "...do they know?"
    QA: "I'm... not sure, really".



  • @CoyneTheDup said:

    Boss: When can you finish project X?
    Me [doing a quick calculation based on 640 hour estimate]: I should be able to have it done by May 1.
    Boss: What about if I assign another resource to the project?
    Me: Well, then, we should be able to finish by March 1.
    Boss: What about if I assign two additional resources to the project?
    Me: Well, then it should be done by February 10<sup>th</sup> or so.

    No. Remember Brooks. Adding resources to a software project makes it later. (I'm deliberately misquoting, mind you.)

    So we are in December or so, I'd guess:
    Me [doing a quick calculation based on 640 hour estimate]: I should be able to have it done by May 1.
    Boss: What about if I assign another resource to the project?
    Me: Well, then, we should be able to finish by June 1.
    Boss: What about if I assign two additional resources to the project?
    Me: Well, then it should be done by August 1 or so.

    Oh, and if you didn't complain as you went about the missing resources, you are TRWTF.

    In this case, you have learned the most important lesson in project scheduling. "Promises" (even if they are speculative estimates, i.e. guesses) of completion dates will be remembered absolutely and forever. The conditions on which those "promises" are based will be forgotten before you have finished saying them.



  • @The_Quiet_One said:

    CTO: What's going on? The thing is broken.
    Me: I was just in the middle of stuff.
    CTO: What do you mean? Why is it broken?
    Me: Because... I was working on stuff.
    CTO: But it's broken.
    Me: Yes. Yes, it is. Because I'm in the middle of refactoring something.
    CTO: But why is it broken?
    Me: It's broken because I haven't finished what I'm working on yet!
    CTO: But it's a new feature. Why would an added feature break existing features?
    Me: Because... nevermind. I'll fix it by the end of the day.

    Me: It's not broken, this is just planned downtime while I reconfigure the flux capacitors to dynamically optimize the new feature. It will be up by the end of the day.

    Lorum ipsum Discourse sit amet


  • Garbage Person

    Oh, the hardware is perfectly capable. That stuff hasn't changed since the 80's.

    The controller software, though...


  • 🚽 Regular

    You're completely misunderstanding The Mythical Man Month. The idea isn't that no matter what any project has an inverse relation between number of resources and eta. If that were true every software company should be a one-developer team.

    The fallacy Brooks is describing is if after starting a project you see the deadline slipping you should avoid the temptation of adding brand new resources, since the process of finding them, fitting them training them and then delegating tasks makes the whole thing take longer.

    If you plan from the start how many resources you have and plan the tasks out intelligently so that they are working efficiently by identifying critical path, their skills, etc then you'll have a successful project. Brooks was NOT at all saying you should never have more than one person on a team to ensure the project finishes at the earliest time. That's preposterous.



  • No, I understand it perfectly fine. You perhaps didn't bother reading where I said I was deliberately misquoting Brooks.



  • Hey Discoursedevs! Where's the "dislike" button? (This is not the same as the "stop liking" button...)


  • BINNED

    Negative reinforcement is not civilized.


  • 🚽 Regular

    My apologies. Perhaps I shouldn't go here when I'm still in bed looking at my smartphone in the morning.



  • Another thought occurred to me. If this is right at the beginning of the project, then it is quite possible that by the time the resources are available (e.g. after the hiring process...) the project will already be late.


  • 🚽 Regular

    I was under the impression these are readily-available resources that might have been on other less important projects or something. You're right, though, that even if you were hiring contractors, there's going to be some lag time between when you start the hiring process and when they become useful.


  • Discourse touched me in a no-no place

    @AgentDenton said:

    Sales Manager: How long will it take?
    Me: 2 months. Planning, build, testing, deployments, the works.
    Sales Manager: And just build, how long will that take?
    Me: A month 3 months because stuff will be broken and we won't know where without testing.

    FTFY<alas>



  • @Steve_The_Cynic said:

    Oh, and if you didn't complain as you went about the missing resources, you are TRWTF.

    Did not help. You could have complained three minutes after the original discussion and he would have said he didn't remember his promise. The only objective of the discussion was to get you to say the date he wanted to hear.


  • BINNED

    @Steve_The_Cynic said:

    Hey Discoursedevs! Where's the "dislike" button? (This is not the same as the "stop liking" button...)

    We have enough server cooties as it is without the additional load of people going around disliking everything.


  • :belt_onion:

    The official Dislikes topic



  • @AgentDenton said:

    Sales Manager: How long will it take?
    Me: 2 months. Planning, build, testing, deployments, the works.
    Sales Manager: And just build, how long will that take?

    Stuff that "a month" thing. The correct response (aside possibly for reaching into your back pocket for the GAU-8 you keep there in case of, um, cases) is, "I don't answer meaningless questions like that." Substitute "stupid" for "meaningless" if you're in a bad mood. Or say, "You know, you've just shown that there is such a thing as a stupid question."


  • ♿ (Parody)

    @Steve_The_Cynic said:

    Where's the "dislike" button?

    Thinking about this, you might try the CAPSLOCK key. It's not an official standard, but some people around here seem to get by with it.


  • Java Dev

    That's for yelling, not for hates.


  • ♿ (Parody)

    @PleegWat said:

    That's for yellingranting, not for hates.

    FTFBR



  • Yeah, the problem isn't HAVING people initially, its ADDING people to a project in motion.



  • @NeighborhoodButcher said:

    In a certain Korean corporation, discussions with Korean management (KM) look like this:

    KM: Urgent issue! Do [insert stupid shit] by the end of the day!
    Me: Maybe instead of [insert stupid shit] we should do [insert something reasonable]?
    KM: (get angry and literally stop talking to me for a month, because I responded in a non-obedient tone, but still require to carry on all tasks, which I don't know they exist, because the KM stopped talking to me)

    The sad part is, this is not exaggerated. A coworker after such incident, got stopped being called by name, but "[division name] member". At least he was being mentioned in emails.

    Send 'em a link to the "Bad Attitude" Air Crash Investigation episode sometime...because just like having an autocrat in the left seat can leave a jumbo jet flying straight into the ground, having an autocrat managing a company can fly that company into the ground.


  • :belt_onion:

    That is a fascinating case on that subject by the way. Very interesting indeed



  • @tarunik said:

    Bad Attitude" Air Crash Investigation

    That's Korean Air Cargo Flight 8509, if you want to skip the dumb TV show and just skip directly to the Wikipedia article.

    Actually that's not the flight I was thinking of-- there was another Korean airline that had a crash due to the flight crew being too afraid to overrule the captain, but right now I can't recall what it was. I remember a few years ago, Korean airlines went through a big retraining thing, trying to get their co-pilots to be less timid and speak-up when they noticed something wrong.


  • area_pol

    I feel that's the ultimate ending my employer is heading for. In all seriousness, what could be the outcome when a big corporation tries to build an OS, but managers and even line workers do not talk to each other. Non Asian workers are officially forbidden from telling an Asian worker about a mistake he made. If an Asian worker somehow feels offended (for example by reporting a bug in his code or doing a negative code review), he will simply stop communicating at all. Can you even imagine teams which need to work closely together, not talking to each other? Can you imagine a library dev team not creating a required interface, because a non-Asian person submitted the request? That's the sad reality of Tizen development. And what's worse is they do not perceive this as a problem, because it stems from their society model, where everyone has a rank and people with higher ranks disregard people with lower ones. Hell, we even have a numerical employee level assigned to make this absurd notion easier to implement in practice.



  • I don't get how a country with a worker culture like that is actually manufacturing cars and TVs and such and actually being successful at it. Is it just lucking-out and having really, really good bosses so that they don't need employees saying, "wow, this is a dumb idea"?

    I mean, even Japanese companies encourage process improvement ideas from all their employees.


  • ♿ (Parody)

    @blakeyrat said:

    I mean, even Japanese companies encourage process improvement ideas from all their employees.

    From all their Japanese employees. They're still incredibly racist on that front, too. And even so, there's a lot of deferral to authority that goes on.


  • area_pol

    That's a mystery we all are wondering about. Maybe that process somehow works in hardware manufacturing, where the margin of error is slim to none (after all, you cannot update hardware with a patch). Who knows. All I know, it does not work for software development. But, the management doesn't see any problems, so it all must be fine right? Tizen is the Android killer it's supposed to be, right? Goddamn, even Intel said "fuck off" to Tizen recently (I hope it's official by now, but I don't want to waste my time to confirm).



  • @blakeyrat said:

    if you want to skip the dumb TV show and just skip directly to the Wikipedia article.

    Well -- the TV show isn't that dumb (save for the episode on Lauda Air 004 where they fumbled what the NASA flight tests were doing). But yes -- you do have the correct flight number.

    Is that other flight you were thinking of Korean Air 801?



  • @boomzilla said:

    From all their Japanese employees. They're still incredibly racist on that front, too.

    Well it's a given everything in Japanese society is racist-as-fuck. Not worth mentioning explicitly.

    @boomzilla said:

    And even so, there's a lot of deferral to authority that goes on.

    I think that depends on a lot on the company. Toyota, for example, is the textbook example of a company innovating from low-level employees on up.

    On the other hand, Japanese video game developers seem strictly and strongly top-down. Which is one of the reasons their gaming industry has been on a downslide for almost 10 years now. (Actually, it recently has been getting better. But it's still nowhere near where it was at the peak.)



  • @tarunik said:

    Well -- the TV show isn't that dumb (save for the episode on Lauda Air 004 where they fumbled what the NASA flight tests were doing). But yes -- you do have the correct flight number.

    Usually air crash Wiki articles have a lot more meat to them, since they have access to NTSC reports and such. That one's pretty bare.

    @tarunik said:

    Is that other flight you were thinking of Korean Air 801?

    Yeah that has to be it.



  • If you want the meat, have at it


  • FoxDev

    I like how page 2 is all 'Want to take out a subscription? It's really easy!' :rolleyes:



  • You have sufficient status to get away with saying something like that. Otherwise, hoo-boy.


  • FoxDev

    @AgentDenton said:

    Recently, I've had reasonable line managers that understand the intricacies of estimating these kinds of things. What really grinded my gears was how the Sales Managers would try to tweak the questions for your estimates to lower the time <del>spent</del> <ins>quoted</ins> to the client.

    Sales Manager: How long will it take?
    Me: 2 months. Planning, build, testing, deployments, the works.
    Sales Manager: And just build, how long will that take?
    Me: A month.

    Then sales manager turns around and promises the client a production deployment within a month of go-ahead 😡

    nah. the correct sequence of events is:

    Sales Manager: How long will it take?
    Me: 2 months. Planning, build, testing, deployments, the works.
    Sales Manager: And just build, how long will that take?
    Me: Still two months.
    Sales Manager: Are you sure. we're just talking about the build here?
    Me: Yup. that'll take two months.



  • @accalia said:

    Sales Manager: How long will it take?
    Me: 2 months. Planning, build, testing, deployments, the works.
    Sales Manager: And just build, how long will that take?
    Me: Still two months.
    Sales Manager: Are you sure. we're just talking about the build here?
    Me: Yup. that'll take two months.

    Sales Manager: So planning, testing and deployment take no time at all. I'll be sure to remember that!


  • Grade A Premium Asshole

    @accalia said:

    Sales Manager: How long will it take?
    Me: 2 months. Planning, build, testing, deployments, the works.
    Sales Manager: And just build, how long will that take?
    Me: Still two months.
    Sales Manager: Are you sure. we're just talking about the build here?
    Me: Yup. that'll take two months.

    @TwelveBaud said:

    Sales Manager: So planning, testing and deployment take no time at all. I'll be sure to remember that!

    And right here we have a good contrast between intentions and consequences.


  • FoxDev

    @TwelveBaud said:

    Sales Manager: So planning, testing and deployment take no time at all. I'll be sure to remember that!

    As long as i always include the testing and deployment time in my estimates of build time that's absolutely correct.

    of course if i work with a sales manager like that... one of us won't be at the company long.

    no threat, no warning, just stating fact.



  • I once endured a major rage-session because I had the utter temerity to highlight some important text in red, in an email message. Serious rage. Rage that made you want to flee.

    I'm still careful to use magenta instead of red.



  • Is your boss a bull?


  • BINNED

    @CoyneTheDup said:

    I once endured a major rage-session because I had the utter temerity to highlight some important text

    Damn right! You kids with your fancy HTMLs, get off my lawn! I'll allow Markdown-like syntax, but that's it. This far, no further!

    @Boner said:

    Is your boss a bull?

    That would matter only if he used the <blink> tag as well. Bulls don't have anything against colour red, it's the movement of the fabric that gets them going. It's red due to tradition, and likely because it's visually striking as well.


Log in to reply