2

We have a build server at work that handles our software releases. It runs a particular version of the tools.

I have updated my tools and noticed that my builds were failing locally. I investigated this further and I know the problem is caused by one of the tools, but I wasn't able to find an easy solution even though I know the exact cause.

I have a fairly high work load right now, so I haven't said anything yet. I simply downgraded my own tools to match the build server. I am not looking to take on any extra work right now...

I know the build server will get updated eventually (could be months, could be hours, it is about a year behind the official releases right now). Should I just wait until the builds start to fail to deal with it, or be proactive and deal with it now even though it's just adding more work to my plate? I am positive it will be dumped on me when it happens.

  • 1
    If it's dumped on you, you simply prioritize it against other tasks and provide work estimates like usual. There's no reason this should increase your weekly workload suddenly. – Chris Nov 14 '18 at 0:59
  • Who, if anyone, is responsible for the build server? – Mawg Nov 14 '18 at 8:04
  • 4
    Frankly speaking, if I would update the build server, notice this issue and spend significant time to evaluate the problem and you would tell me afterwards "Yeah, I've seen this issue a year ago on my machine, but I didn't say anything, because $reasons" I would be pretty mad at you. Add it to your issue tracker. – Simon Nov 14 '18 at 8:41
  • Surely THIS one is really software engineering! Software specific questions are taking over the site! – Fattie Nov 14 '18 at 13:24
  • @Chris, I would love to agree with you, but that has not been my experience lately... (In this job at least). – Catsunami Nov 14 '18 at 15:39
15

Should I just wait until the builds start to fail to deal with it, or be proactive and deal with it now even though it's just adding more work to my plate?

It is always better to be proactive.

Even though you are full with tasks, you should inform this to your team leader or manager ASAP, so this can be taken care of.

By doing so, you could spare your whole team and company future issues and bugs that could come out. You could also spare them from monetary losses resulting from downtime due to the bugs.

Withholding this information is just a big trouble waiting to happen (and could backfire to you if you don't report it and it fails). Do inform about your findings, and document them if possible.

  • 1
    The whole thing is a total non-issue. Every piece of software in the universe is suffering incredibly code debt, and is hanging on by a thread. All you do is just openly mention, in passing, to everyone "oh don't forget about Blah". So, along with the 19,500 other "blahs" that need fixing at that instant. It's a total non-issue. Deal. – Fattie Nov 14 '18 at 15:47
  • Thanks for your response. I agree, a big part of me wants to be proactive. I just feel over-loaded right now and I was trying to avoid having to fix this as well as the thousand other things that I'm doing. – Catsunami Nov 14 '18 at 15:48
  • @Catsunami you don't need to do much tho, just write a quick email with the situation and that's it. Then it's your superior's problem and you did your best – Hobbamok Mar 26 at 13:51
  • 1
    @Hobbamok, well what do you know, it's my JIRA issue next sprint ;) I knew it would come back to get me. – Catsunami Mar 26 at 15:53
  • @Catsunami good think you knew already this could happen eventually :) – DarkCygnus Mar 26 at 17:15
4

Should I point out that a tool update will break our builds in the future?

Yes you should.

That way, your boss can find a way to remedy the situation, or defer the problem to later - perhaps by not updating the tools until there is sufficient free time to deal with the problem.

And if you are worried that something will be "dumped on you", then you just make sure to work with your boss to have them help decide what should come off your plate at that time.

2

To put it simply, it's a bug. There's nothing exceptional to it. So register it in your bug tracker and continue with your assigned tasks. Let the organization unleash its full power (ahem) and handle it. When you work on it in future, don't look at this in negative light: it could be that fixing bugs is your job.

(If your organization penalizes people who file bugs, it's a wholly different topic. Similarly, if your organization's net effect is negative when it comes to helping you fix the bugs. I can only hope it's not the case.)

  • This. Log a bug about it and document everything you've figured out about what the issue is and what possible solutions there are. The company will then have the information it needs to fix the issue when they decide it's time to do so (and if it ends up falling in your lap, you'll have your own notes to remind you about what you were doing.) – Steve-O Nov 14 '18 at 14:42
0

I am positive it will be dumped on me when it happens.

I would defer it until I have a solution, it always best to present a problem with a solution.

Unless I was solely responsible for the server in which case I would be controlling when the tool updates anyway. The main reasons I would defer it is that quite often tools with problems are fixed in the next update. This would solve my issue for me. Quite probably I would just resolve it and wouldn't even mention it as it is a fairly common issue with simple resolution strategies, no need for any drama.

If it did get dumped on me, my immediate solution would be to roll back to the old tools and contact the vendor for assistance.

  • 1
    This is absurd. Warning your colleagues to be careful not to update the server because doing so will break things is obviously the right and helpful thing to do, until there is a resolution available. Stop worrying about your own image of invincibility at the expense of success, and start giving consideration to what helps the overall effort you are employed to be a part of. – Chris Stratton Nov 14 '18 at 4:41
  • 1
    @ChrisStratton if it's not your responsibility then why would you? Quite possibly the whole reason the server hasn't been updated for a year is precisely because of compatability issues. Jumping around like a superhero isn't going to impress anyone. I have a server running Windows NT Server 2000 (for a solid reason), wouldn't be impressed if a dev said if I updated it things would break... if it is the OP's resonsibility, then still no need to be dramatic, just don't update the tool until there is a version which works. – Kilisi Nov 14 '18 at 14:37
  • 2
    Pointing out an expected issue before it causes problems for your team is not "jumping around like a superhero" but rather merely "being a decent human being" – Chris Stratton Nov 14 '18 at 14:39
  • 1
    This is the only sensible, real-world answer here. – Fattie Nov 14 '18 at 15:45
  • 1
    I don't agree with the downvotes you've been getting (so I +1ed you). I think this is a sensible solution, just a different one. In fact I think I'm going to do something that is a combination of the solutions - I'll file a JIRA for it, but I'll also note that we should wait for the next tool release to see if it is fixed. I looked through the change logs in this tool release and I see there was a functional change, but it doesn't affect our code anyway. – Catsunami Nov 14 '18 at 15:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.