Should I point out that a tool update will break our builds in the future?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty{ margin-bottom:0;
}
up vote
2
down vote
favorite
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.
software-industry software-development
edited Nov 14 at 0:08
DarkCygnus
32.4k1362141
asked Nov 14 at 0:01
Catsunami
1657
|
show 6 more comments
up vote
2
down vote
favorite
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.
software-industry software-development
edited Nov 14 at 0:08
DarkCygnus
32.4k1362141
asked Nov 14 at 0:01
Catsunami
1657
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 at 0:59
Who, if anyone, is responsible for the build server?
– Mawg
Nov 14 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 at 8:41
Surely THIS one is really software engineering! Software specific questions are taking over the site!
– Fattie
Nov 14 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 at 15:39
|
show 6 more comments
up vote
2
down vote
favorite
up vote
2
down vote
favorite
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.
software-industry software-development
edited Nov 14 at 0:08
DarkCygnus
32.4k1362141
asked Nov 14 at 0:01
Catsunami
1657
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.
software-industry software-development
software-industry software-development
edited Nov 14 at 0:08
DarkCygnus
32.4k1362141
asked Nov 14 at 0:01
Catsunami
1657
edited Nov 14 at 0:08
DarkCygnus
32.4k1362141
asked Nov 14 at 0:01
Catsunami
1657
edited Nov 14 at 0:08
DarkCygnus
32.4k1362141
edited Nov 14 at 0:08
DarkCygnus
32.4k1362141
edited Nov 14 at 0:08
DarkCygnus
32.4k1362141
32.4k1362141
asked Nov 14 at 0:01
Catsunami
1657
asked Nov 14 at 0:01
Catsunami
1657
asked Nov 14 at 0:01
Catsunami
1657
1657
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 at 0:59
Who, if anyone, is responsible for the build server?
– Mawg
Nov 14 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 at 8:41
Surely THIS one is really software engineering! Software specific questions are taking over the site!
– Fattie
Nov 14 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 at 15:39
|
show 6 more comments
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 at 0:59
Who, if anyone, is responsible for the build server?
– Mawg
Nov 14 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 at 8:41
Surely THIS one is really software engineering! Software specific questions are taking over the site!
– Fattie
Nov 14 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 at 15:39
1
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 at 0:59
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 at 0:59
Who, if anyone, is responsible for the build server?
– Mawg
Nov 14 at 8:04
Who, if anyone, is responsible for the build server?
– Mawg
Nov 14 at 8:04
4
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 at 8:41
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 at 8:41
Surely THIS one is really software engineering! Software specific questions are taking over the site!
– Fattie
Nov 14 at 13:24
Surely THIS one is really software engineering! Software specific questions are taking over the site!
– Fattie
Nov 14 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 at 15:39
@Chris, I would love to agree with you, but that has not been my experience lately... (In this job at least).
– Catsunami
Nov 14 at 15:39
|
show 6 more comments
4 Answers
4
active
oldest
votes
up vote
13
down vote
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.
answered Nov 14 at 0:03
DarkCygnus
32.4k1362141
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 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 at 15:48
add a comment |
up vote
4
down vote
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.
answered Nov 14 at 2:05
Joe Strazzere
237k115693986
add a comment |
up vote
2
down vote
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.)
answered Nov 14 at 8:23
kubanczyk
1,505913
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 at 14:42
add a comment |
up vote
0
down vote
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.
answered Nov 14 at 3:03
Kilisi
107k59241418
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 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 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 at 14:39
1
This is the only sensible, real-world answer here.
– Fattie
Nov 14 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 at 15:51
|
show 2 more comments
StackExchange.ready(function () {
$("#show-editor-button input, #show-editor-button button").click(function () {
var showEditor = function() {
$("#show-editor-button").hide();
$("#post-form").removeClass("dno");
StackExchange.editor.finallyInit();
};
var useFancy = $(this).data('confirm-use-fancy');
if(useFancy == 'True') {
var popupTitle = $(this).data('confirm-fancy-title');
var popupBody = $(this).data('confirm-fancy-body');
var popupAccept = $(this).data('confirm-fancy-accept-button');
$(this).loadPopup({
url: '/post/self-answer-popup',
loaded: function(popup) {
var pTitle = $(popup).find('h2');
var pBody = $(popup).find('.popup-body');
var pSubmit = $(popup).find('.popup-submit');
pTitle.text(popupTitle);
pBody.html(popupBody);
pSubmit.val(popupAccept).click(showEditor);
}
})
} else{
var confirmText = $(this).data('confirm-text');
if (confirmText ? confirm(confirmText) : true) {
showEditor();
}
}
});
});
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
13
down vote
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.
answered Nov 14 at 0:03
DarkCygnus
32.4k1362141
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 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 at 15:48
add a comment |
up vote
13
down vote
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.
answered Nov 14 at 0:03
DarkCygnus
32.4k1362141
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 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 at 15:48
add a comment |
up vote
13
down vote
up vote
13
down vote
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.
answered Nov 14 at 0:03
DarkCygnus
32.4k1362141
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.
answered Nov 14 at 0:03
DarkCygnus
32.4k1362141
edited Nov 14 at 0:09
answered Nov 14 at 0:03
DarkCygnus
32.4k1362141
answered Nov 14 at 0:03
DarkCygnus
32.4k1362141
answered Nov 14 at 0:03
DarkCygnus
32.4k1362141
32.4k1362141
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 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 at 15:48
add a comment |
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 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 at 15:48
1
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 at 15:47
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 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 at 15:48
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 at 15:48
add a comment |
up vote
4
down vote
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.
answered Nov 14 at 2:05
Joe Strazzere
237k115693986
add a comment |
up vote
4
down vote
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.
answered Nov 14 at 2:05
Joe Strazzere
237k115693986
add a comment |
up vote
4
down vote
up vote
4
down vote
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.
answered Nov 14 at 2:05
Joe Strazzere
237k115693986
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.
answered Nov 14 at 2:05
Joe Strazzere
237k115693986
answered Nov 14 at 2:05
Joe Strazzere
237k115693986
answered Nov 14 at 2:05
Joe Strazzere
237k115693986
answered Nov 14 at 2:05
Joe Strazzere
237k115693986
237k115693986
add a comment |
add a comment |
up vote
2
down vote
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.)
answered Nov 14 at 8:23
kubanczyk
1,505913
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 at 14:42
add a comment |
up vote
2
down vote
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.)
answered Nov 14 at 8:23
kubanczyk
1,505913
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 at 14:42
add a comment |
up vote
2
down vote
up vote
2
down vote
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.)
answered Nov 14 at 8:23
kubanczyk
1,505913
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.)
answered Nov 14 at 8:23
kubanczyk
1,505913
edited Nov 14 at 15:07
answered Nov 14 at 8:23
kubanczyk
1,505913
answered Nov 14 at 8:23
kubanczyk
1,505913
answered Nov 14 at 8:23
kubanczyk
1,505913
1,505913
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 at 14:42
add a comment |
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 at 14:42
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 at 14:42
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 at 14:42
add a comment |
up vote
0
down vote
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.
answered Nov 14 at 3:03
Kilisi
107k59241418
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 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 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 at 14:39
1
This is the only sensible, real-world answer here.
– Fattie
Nov 14 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 at 15:51
|
show 2 more comments
up vote
0
down vote
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.
answered Nov 14 at 3:03
Kilisi
107k59241418
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 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 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 at 14:39
1
This is the only sensible, real-world answer here.
– Fattie
Nov 14 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 at 15:51
|
show 2 more comments
up vote
0
down vote
up vote
0
down vote
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.
answered Nov 14 at 3:03
Kilisi
107k59241418
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.
answered Nov 14 at 3:03
Kilisi
107k59241418
answered Nov 14 at 3:03
Kilisi
107k59241418
answered Nov 14 at 3:03
Kilisi
107k59241418
answered Nov 14 at 3:03
Kilisi
107k59241418
107k59241418
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 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 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 at 14:39
1
This is the only sensible, real-world answer here.
– Fattie
Nov 14 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 at 15:51
|
show 2 more comments
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 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 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 at 14:39
1
This is the only sensible, real-world answer here.
– Fattie
Nov 14 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 at 15:51
1
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 at 4:41
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 at 4:41
1
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 at 14:37
@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 at 14:37
2
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 at 14:39
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 at 14:39
1
1
This is the only sensible, real-world answer here.
– Fattie
Nov 14 at 15:45
This is the only sensible, real-world answer here.
– Fattie
Nov 14 at 15:45
1
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 at 15:51
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 at 15:51
|
show 2 more comments
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f122694%2fshould-i-point-out-that-a-tool-update-will-break-our-builds-in-the-future%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
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 at 0:59
Who, if anyone, is responsible for the build server?
– Mawg
Nov 14 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 at 8:41
Surely THIS one is really software engineering! Software specific questions are taking over the site!
– Fattie
Nov 14 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 at 15:39