Mixing
Sharing self-developed but untested tools or processes with colleagues
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
36
down vote
favorite
As a QA tester for a software suite, I find that I have to install/uninstall builds daily, change system configurations in batches, etc. I find I regularly create .bat's, .vbs's, and .exe's to script actions that I have to repeat regularly with my job. I have a folder of these on my desktop, and use them fairly frequently. I didn't bother with any sort of error handling into them because I didn't have "approval" to write them and wanted to minimize the dev time (most were written in less than 20 minutes), and never expected them to leave my desktop.
The problem is, coworkers have seen me using them, and they would like me to share. If I distribute these utilities, I know that I will suddenly have to support them and anything wrong will be blamed on me, possibly implicating me in damages, and damaging my reputation for something that is really outside of my job description anyway. I'm willing to take the risk of some edge case causing an error condition on my computer (I will probably be able to fix it with little effort), but I'm hesitant to allow that on coworkers computers that I have no control over.
I want to share the tools I developed but I don't have the time or budget to ensure that they're safe for use by colleagues that aren't aware of how they work or what could go wrong.
- Should I mention the risks and keep these tools to myself?
- If I want to share them, how do I ensure that they're used with caution and that any problems caused by their use don't reflect on me?
- Should I make the case for further development of these tools and, if so, how?
teamwork
edited Nov 5 '15 at 12:06
Lilienthal♦
53.9k36183218
asked Nov 4 '15 at 21:19
Sidney
2,50552040
 |Â
show 5 more comments
up vote
36
down vote
favorite
As a QA tester for a software suite, I find that I have to install/uninstall builds daily, change system configurations in batches, etc. I find I regularly create .bat's, .vbs's, and .exe's to script actions that I have to repeat regularly with my job. I have a folder of these on my desktop, and use them fairly frequently. I didn't bother with any sort of error handling into them because I didn't have "approval" to write them and wanted to minimize the dev time (most were written in less than 20 minutes), and never expected them to leave my desktop.
The problem is, coworkers have seen me using them, and they would like me to share. If I distribute these utilities, I know that I will suddenly have to support them and anything wrong will be blamed on me, possibly implicating me in damages, and damaging my reputation for something that is really outside of my job description anyway. I'm willing to take the risk of some edge case causing an error condition on my computer (I will probably be able to fix it with little effort), but I'm hesitant to allow that on coworkers computers that I have no control over.
I want to share the tools I developed but I don't have the time or budget to ensure that they're safe for use by colleagues that aren't aware of how they work or what could go wrong.
- Should I mention the risks and keep these tools to myself?
- If I want to share them, how do I ensure that they're used with caution and that any problems caused by their use don't reflect on me?
- Should I make the case for further development of these tools and, if so, how?
teamwork
edited Nov 5 '15 at 12:06
Lilienthal♦
53.9k36183218
asked Nov 4 '15 at 21:19
Sidney
2,50552040
5
@JaneS I'm not so sure. I could just as easily replace the premise with "I found a great new way to skin a cat, but it hasn't been put through peer review, and I can't gaurentee it will work in 100% of cases"
– Sidney
Nov 4 '15 at 21:34
16
If your employer looks negatively upon you creating things that let you do your job better, faster & more efficiently, you ought to find a new place to work that will appreciate your efforts.
– alroc
Nov 4 '15 at 21:39
6
Sell the company your toolkit, then everyone wins
– Kilisi
Nov 4 '15 at 21:51
1
"possibly implicating me in damages". That's complete bull. For starters, you developed these on work time, so you don't own them, your company does. If your coworkers are doing the same job as you, they also have the skills to fix bugs in them. If you want to be proactive, you could suggest to your line manager that you share them and that you want to allow a couple of hours a week for fixing things that people find. No sane manager will knock back someone trying to improve their team's productivity.
– Graham
Nov 5 '15 at 10:45
3
Voted to reopen. I've retitled this post, reformulated your core question and expanded it with a few other questions to detail what you're trying to accomplish (and avoid this being off-topic as a generic advice question). While this question is (still) not perfect, I frankly don't get why this was closed as company-specific.
– Lilienthal♦
Nov 5 '15 at 12:08
 |Â
show 5 more comments
up vote
36
down vote
favorite
up vote
36
down vote
favorite
As a QA tester for a software suite, I find that I have to install/uninstall builds daily, change system configurations in batches, etc. I find I regularly create .bat's, .vbs's, and .exe's to script actions that I have to repeat regularly with my job. I have a folder of these on my desktop, and use them fairly frequently. I didn't bother with any sort of error handling into them because I didn't have "approval" to write them and wanted to minimize the dev time (most were written in less than 20 minutes), and never expected them to leave my desktop.
The problem is, coworkers have seen me using them, and they would like me to share. If I distribute these utilities, I know that I will suddenly have to support them and anything wrong will be blamed on me, possibly implicating me in damages, and damaging my reputation for something that is really outside of my job description anyway. I'm willing to take the risk of some edge case causing an error condition on my computer (I will probably be able to fix it with little effort), but I'm hesitant to allow that on coworkers computers that I have no control over.
I want to share the tools I developed but I don't have the time or budget to ensure that they're safe for use by colleagues that aren't aware of how they work or what could go wrong.
- Should I mention the risks and keep these tools to myself?
- If I want to share them, how do I ensure that they're used with caution and that any problems caused by their use don't reflect on me?
- Should I make the case for further development of these tools and, if so, how?
teamwork
edited Nov 5 '15 at 12:06
Lilienthal♦
53.9k36183218
asked Nov 4 '15 at 21:19
Sidney
2,50552040
As a QA tester for a software suite, I find that I have to install/uninstall builds daily, change system configurations in batches, etc. I find I regularly create .bat's, .vbs's, and .exe's to script actions that I have to repeat regularly with my job. I have a folder of these on my desktop, and use them fairly frequently. I didn't bother with any sort of error handling into them because I didn't have "approval" to write them and wanted to minimize the dev time (most were written in less than 20 minutes), and never expected them to leave my desktop.
The problem is, coworkers have seen me using them, and they would like me to share. If I distribute these utilities, I know that I will suddenly have to support them and anything wrong will be blamed on me, possibly implicating me in damages, and damaging my reputation for something that is really outside of my job description anyway. I'm willing to take the risk of some edge case causing an error condition on my computer (I will probably be able to fix it with little effort), but I'm hesitant to allow that on coworkers computers that I have no control over.
I want to share the tools I developed but I don't have the time or budget to ensure that they're safe for use by colleagues that aren't aware of how they work or what could go wrong.
- Should I mention the risks and keep these tools to myself?
- If I want to share them, how do I ensure that they're used with caution and that any problems caused by their use don't reflect on me?
- Should I make the case for further development of these tools and, if so, how?
teamwork
edited Nov 5 '15 at 12:06
Lilienthal♦
53.9k36183218
asked Nov 4 '15 at 21:19
Sidney
2,50552040
edited Nov 5 '15 at 12:06
Lilienthal♦
53.9k36183218
edited Nov 5 '15 at 12:06
Lilienthal♦
53.9k36183218
edited Nov 5 '15 at 12:06
Lilienthal♦
53.9k36183218
53.9k36183218
asked Nov 4 '15 at 21:19
Sidney
2,50552040
asked Nov 4 '15 at 21:19
Sidney
2,50552040
asked Nov 4 '15 at 21:19
Sidney
2,50552040
2,50552040
5
@JaneS I'm not so sure. I could just as easily replace the premise with "I found a great new way to skin a cat, but it hasn't been put through peer review, and I can't gaurentee it will work in 100% of cases"
– Sidney
Nov 4 '15 at 21:34
16
If your employer looks negatively upon you creating things that let you do your job better, faster & more efficiently, you ought to find a new place to work that will appreciate your efforts.
– alroc
Nov 4 '15 at 21:39
6
Sell the company your toolkit, then everyone wins
– Kilisi
Nov 4 '15 at 21:51
1
"possibly implicating me in damages". That's complete bull. For starters, you developed these on work time, so you don't own them, your company does. If your coworkers are doing the same job as you, they also have the skills to fix bugs in them. If you want to be proactive, you could suggest to your line manager that you share them and that you want to allow a couple of hours a week for fixing things that people find. No sane manager will knock back someone trying to improve their team's productivity.
– Graham
Nov 5 '15 at 10:45
3
Voted to reopen. I've retitled this post, reformulated your core question and expanded it with a few other questions to detail what you're trying to accomplish (and avoid this being off-topic as a generic advice question). While this question is (still) not perfect, I frankly don't get why this was closed as company-specific.
– Lilienthal♦
Nov 5 '15 at 12:08
 |Â
show 5 more comments
5
@JaneS I'm not so sure. I could just as easily replace the premise with "I found a great new way to skin a cat, but it hasn't been put through peer review, and I can't gaurentee it will work in 100% of cases"
– Sidney
Nov 4 '15 at 21:34
16
If your employer looks negatively upon you creating things that let you do your job better, faster & more efficiently, you ought to find a new place to work that will appreciate your efforts.
– alroc
Nov 4 '15 at 21:39
6
Sell the company your toolkit, then everyone wins
– Kilisi
Nov 4 '15 at 21:51
1
"possibly implicating me in damages". That's complete bull. For starters, you developed these on work time, so you don't own them, your company does. If your coworkers are doing the same job as you, they also have the skills to fix bugs in them. If you want to be proactive, you could suggest to your line manager that you share them and that you want to allow a couple of hours a week for fixing things that people find. No sane manager will knock back someone trying to improve their team's productivity.
– Graham
Nov 5 '15 at 10:45
3
Voted to reopen. I've retitled this post, reformulated your core question and expanded it with a few other questions to detail what you're trying to accomplish (and avoid this being off-topic as a generic advice question). While this question is (still) not perfect, I frankly don't get why this was closed as company-specific.
– Lilienthal♦
Nov 5 '15 at 12:08
5
5
@JaneS I'm not so sure. I could just as easily replace the premise with "I found a great new way to skin a cat, but it hasn't been put through peer review, and I can't gaurentee it will work in 100% of cases"
– Sidney
Nov 4 '15 at 21:34
@JaneS I'm not so sure. I could just as easily replace the premise with "I found a great new way to skin a cat, but it hasn't been put through peer review, and I can't gaurentee it will work in 100% of cases"
– Sidney
Nov 4 '15 at 21:34
16
16
If your employer looks negatively upon you creating things that let you do your job better, faster & more efficiently, you ought to find a new place to work that will appreciate your efforts.
– alroc
Nov 4 '15 at 21:39
If your employer looks negatively upon you creating things that let you do your job better, faster & more efficiently, you ought to find a new place to work that will appreciate your efforts.
– alroc
Nov 4 '15 at 21:39
6
6
Sell the company your toolkit, then everyone wins
– Kilisi
Nov 4 '15 at 21:51
Sell the company your toolkit, then everyone wins
– Kilisi
Nov 4 '15 at 21:51
1
1
"possibly implicating me in damages". That's complete bull. For starters, you developed these on work time, so you don't own them, your company does. If your coworkers are doing the same job as you, they also have the skills to fix bugs in them. If you want to be proactive, you could suggest to your line manager that you share them and that you want to allow a couple of hours a week for fixing things that people find. No sane manager will knock back someone trying to improve their team's productivity.
– Graham
Nov 5 '15 at 10:45
"possibly implicating me in damages". That's complete bull. For starters, you developed these on work time, so you don't own them, your company does. If your coworkers are doing the same job as you, they also have the skills to fix bugs in them. If you want to be proactive, you could suggest to your line manager that you share them and that you want to allow a couple of hours a week for fixing things that people find. No sane manager will knock back someone trying to improve their team's productivity.
– Graham
Nov 5 '15 at 10:45
3
3
Voted to reopen. I've retitled this post, reformulated your core question and expanded it with a few other questions to detail what you're trying to accomplish (and avoid this being off-topic as a generic advice question). While this question is (still) not perfect, I frankly don't get why this was closed as company-specific.
– Lilienthal♦
Nov 5 '15 at 12:08
Voted to reopen. I've retitled this post, reformulated your core question and expanded it with a few other questions to detail what you're trying to accomplish (and avoid this being off-topic as a generic advice question). While this question is (still) not perfect, I frankly don't get why this was closed as company-specific.
– Lilienthal♦
Nov 5 '15 at 12:08
 |Â
show 5 more comments
6 Answers
6
active
oldest
votes
up vote
51
down vote
accepted
How can I safely share these utilities without putting myself in harms
way?
Talk with your manager, and explain your dilemma.
Suggest that you be given permission and time to enhance your utilities so that they are more robust, have a sufficient level of error handling, are well documented, and are well-tested on machines other than yours. Then, you could present the enhanced utilities to the team for their use.
As @cbojar wisely suggests, if your team has an internal tools person or group - you could turn the finished product over to them for continued support.
I was fortunate enough to have a terrific "toolsmith" on my last QA Team. He was a wiz at creating these sorts of tools, tips, and utilities. He shared your concerns, but I urged him share his work with the rest of the team. He eventually did - and everyone benefited. The team became more productive, and the toolsmith got a nicer bonus at the end of the year, and the appreciation of the team.
You might find that your boss would welcome this approach. Or you might find that she/he would rather you not share.
answered Nov 4 '15 at 21:38
Joe Strazzere
223k104651918
5
If the OP's company has an internal tools team, they may even be able to hand off maintenance of the scripts to someone else.
– cbojar
Nov 4 '15 at 21:43
1
Also, don't neglect to QA the tools. Make them a real "product". Not that I've ever had to track down a bug that was in a tool QA was using instead of my package. grumble.
– ColleenV
Nov 4 '15 at 21:56
1
+1 for manager approval. You'll need higher up backings before you start running off and doing tool testing on your colleague's computers. I was in a similar situation in a call center, and I created tools that provided a huge productivity boost to everyone, but I had to spend time to troubleshoot the tools, and also add in different ways of triggering them since everyone are not me.
– Nelson
Nov 5 '15 at 0:44
1
If I understood this right, you are suggesting that the OP should take on developing and supporting these tools. That can be a lot of work in itself, and lead to a shift in the type of work he is doing. He may not be willing to do this, not just because of the issue of taking on responsibility, but simply because it's not the kind of work he signed up for. I know I wouldn't want to do it. But then I'm in academia so I don't really know how things work at companies.
– Szabolcs
Nov 5 '15 at 11:01
suggest improvements |Â
up vote
7
down vote
You are using these tools to make your job easier and your coworkers have seen that. That means they all have a need for it, or are even unhappy with the situation they face at work.
I think you should talk to your team lead or manager about this. Be prepared, show them the benefits of the automated approach and how it frees up time for other things, like actual testing. Then let them decide. A good manager will see how this can increase the efficiency of the team.
If you repeat the same tedious setup process every day and it takes five minutes, then investing 20 minutes to automate it will amortize after less than a week. In fact, it saves an hour of work for a team of five every week. It's also less error-prone if it is automated because you cannot accidentally click the wrong stuff because it's boring time consuming clicking and waiting.
This XKCD comic explains in an easy way when automation of tasks makes sense.
You can suggest that you can maintain and improve the things for the whole team. Move them from your desktop to a company git and let everyone benefit. That's in the company's interest and your manager will likely be happy to give you time to further improve if properly convinced. Hard facts can go a long way even for the most untechnical manager.
answered Nov 4 '15 at 21:47
simbabque
3,13911022
suggest improvements |Â
up vote
3
down vote
First, creating tools can make you very valuable to your team and employer. You need to gauge the effectiveness of your tools and make your decision based on that. For me, I once developed a reporting system that turned 2 hours of work into 5 seconds of work--and no more missed deadlines.
If you're worried about damaging something, I'd suggest to work that out before releasing anything to your coworkers. You'll need to make this decision after weighing risks.
For me, usually there are little to no risks involved in my scripts and tools. I usually provide them with an AS-IS disclaimer and provide no support. However, it's gotten to the point that I'm formally asked to fix or maintain certain tools that improve workplace productivity.
Finally, if you do have an internal team, it's great to engage them with your work. This can help prevent code rot. In my case, I added a birthday reminder to one of my tools. After getting laid-off and shortly after my next birthday, I was asked to cover for someone on extended leave. I found out, the team maintaining my code had recommended me because they had worked with my code recently.
answered Nov 5 '15 at 1:10
Nathan Goings
27917
suggest improvements |Â
up vote
2
down vote
I think you are making a mountain out of a molehill. Sharing off-the-cuff project specific tools and scripts happens frequently in the development world. Quite frankly, any software developer who isn't often creating their own productivity enhancement "tools" is almost certainly not going to be a very good developer. When developers share these types of tools then everyone knows what they are getting.
What is more likely to happen versus getting blamed is if it turns out that your tool really is useful then the source code/scripts will be added to the software CM system and then the developers will all start adding their desired features. One day your rather mundane tool may blossom into a quite slick application that is a core part of the project's (or even company) development process.
If people ask you to "support" the tools then you just be honest and tell them "I only created the tool for my personal use. I can give you the source code and you can modify it to your liking if it doesn't do what you want". Very simple, you don't end up owning the tools simply because you wrote them and others want to use them.
answered Nov 5 '15 at 18:35
Dunk
1,10278
suggest improvements |Â
up vote
0
down vote
One way to address the support issue is to make these tools a company-internal open source, peer-supported project. That lets others get involved in fixing the bugs rather than uour having to bear all that burden. Downside is that you'd be giving up some degree of control over the code, and in accepting their fixes you also run the risk of those creating new bugs.... but if you can't confince management to pay you for time spent polishing these tools, this is probably the best way to share both costs and benefits, and it lets you pick other programmers' brains for solutions to tough problems.
answered Nov 5 '15 at 19:29
keshlam
41.5k1267144
suggest improvements |Â
up vote
-3
down vote
As a software developer I too had the same problem. I think there's a very simple and easy way for you to handle this:
Upload your tools, frameworks, utilities to GitHub with an appropriate license. For example I've used the MIT license that has following text:
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
I cannot give legal advice, so check what license works best for you yourself.
And giving the link to the tool you can specify something like alpha or beta version - that usually gives a pretty good hint that the software can have bugs or missing features.
That should negate any tension in case if your tool doesn't work as intended. At least legally.
If asked to make updates to the tool from a college - tell that you do that in your free time and can't promise any deadlines. If asked from a manager - make a fork and continue the development.
answered Nov 5 '15 at 2:50
test
46329
6
This would likely open you up to intellectual property suites since you created these products on company time. I suggest not following this advice without first speaking with your manager.
– Brandon
Nov 5 '15 at 2:52
That should negate any tension in case if your tool doesn't work as intended. At least legally.Are you really worried about the person sitting next to you at work personally suing you for damages because of an implied warranty? That must be a dangerous script. If I could sue for damages every time I observed a software bug, I'd be a wealthy man.
– Brandon
Nov 5 '15 at 2:55
1
@Brandon You are wrong, if you're going to develop the tool during company time - you're making a fork ( a clone ), from that point onward it's not your copy of code - it's companies copy. And you are wrong again about person next to you suing you - the person next to you would point a finger at you saying the tool caused a problem. The company(!) could sue you for damages. And could doesn't mean will. And you are wrong the third time about script needing to be dangerous - it could be simply a bug that would corrupt the format of a file and thus - a lot of work needing to be remade.
– test
Nov 5 '15 at 3:51
suggest improvements |Â
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();
);
);
6 Answers
6
active
oldest
votes
6 Answers
6
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
51
down vote
accepted
How can I safely share these utilities without putting myself in harms
way?
Talk with your manager, and explain your dilemma.
Suggest that you be given permission and time to enhance your utilities so that they are more robust, have a sufficient level of error handling, are well documented, and are well-tested on machines other than yours. Then, you could present the enhanced utilities to the team for their use.
As @cbojar wisely suggests, if your team has an internal tools person or group - you could turn the finished product over to them for continued support.
I was fortunate enough to have a terrific "toolsmith" on my last QA Team. He was a wiz at creating these sorts of tools, tips, and utilities. He shared your concerns, but I urged him share his work with the rest of the team. He eventually did - and everyone benefited. The team became more productive, and the toolsmith got a nicer bonus at the end of the year, and the appreciation of the team.
You might find that your boss would welcome this approach. Or you might find that she/he would rather you not share.
answered Nov 4 '15 at 21:38
Joe Strazzere
223k104651918
5
If the OP's company has an internal tools team, they may even be able to hand off maintenance of the scripts to someone else.
– cbojar
Nov 4 '15 at 21:43
1
Also, don't neglect to QA the tools. Make them a real "product". Not that I've ever had to track down a bug that was in a tool QA was using instead of my package. grumble.
– ColleenV
Nov 4 '15 at 21:56
1
+1 for manager approval. You'll need higher up backings before you start running off and doing tool testing on your colleague's computers. I was in a similar situation in a call center, and I created tools that provided a huge productivity boost to everyone, but I had to spend time to troubleshoot the tools, and also add in different ways of triggering them since everyone are not me.
– Nelson
Nov 5 '15 at 0:44
1
If I understood this right, you are suggesting that the OP should take on developing and supporting these tools. That can be a lot of work in itself, and lead to a shift in the type of work he is doing. He may not be willing to do this, not just because of the issue of taking on responsibility, but simply because it's not the kind of work he signed up for. I know I wouldn't want to do it. But then I'm in academia so I don't really know how things work at companies.
– Szabolcs
Nov 5 '15 at 11:01
suggest improvements |Â
up vote
51
down vote
accepted
How can I safely share these utilities without putting myself in harms
way?
Talk with your manager, and explain your dilemma.
Suggest that you be given permission and time to enhance your utilities so that they are more robust, have a sufficient level of error handling, are well documented, and are well-tested on machines other than yours. Then, you could present the enhanced utilities to the team for their use.
As @cbojar wisely suggests, if your team has an internal tools person or group - you could turn the finished product over to them for continued support.
I was fortunate enough to have a terrific "toolsmith" on my last QA Team. He was a wiz at creating these sorts of tools, tips, and utilities. He shared your concerns, but I urged him share his work with the rest of the team. He eventually did - and everyone benefited. The team became more productive, and the toolsmith got a nicer bonus at the end of the year, and the appreciation of the team.
You might find that your boss would welcome this approach. Or you might find that she/he would rather you not share.
answered Nov 4 '15 at 21:38
Joe Strazzere
223k104651918
5
If the OP's company has an internal tools team, they may even be able to hand off maintenance of the scripts to someone else.
– cbojar
Nov 4 '15 at 21:43
1
Also, don't neglect to QA the tools. Make them a real "product". Not that I've ever had to track down a bug that was in a tool QA was using instead of my package. grumble.
– ColleenV
Nov 4 '15 at 21:56
1
+1 for manager approval. You'll need higher up backings before you start running off and doing tool testing on your colleague's computers. I was in a similar situation in a call center, and I created tools that provided a huge productivity boost to everyone, but I had to spend time to troubleshoot the tools, and also add in different ways of triggering them since everyone are not me.
– Nelson
Nov 5 '15 at 0:44
1
If I understood this right, you are suggesting that the OP should take on developing and supporting these tools. That can be a lot of work in itself, and lead to a shift in the type of work he is doing. He may not be willing to do this, not just because of the issue of taking on responsibility, but simply because it's not the kind of work he signed up for. I know I wouldn't want to do it. But then I'm in academia so I don't really know how things work at companies.
– Szabolcs
Nov 5 '15 at 11:01
suggest improvements |Â
up vote
51
down vote
accepted
up vote
51
down vote
accepted
How can I safely share these utilities without putting myself in harms
way?
Talk with your manager, and explain your dilemma.
Suggest that you be given permission and time to enhance your utilities so that they are more robust, have a sufficient level of error handling, are well documented, and are well-tested on machines other than yours. Then, you could present the enhanced utilities to the team for their use.
As @cbojar wisely suggests, if your team has an internal tools person or group - you could turn the finished product over to them for continued support.
I was fortunate enough to have a terrific "toolsmith" on my last QA Team. He was a wiz at creating these sorts of tools, tips, and utilities. He shared your concerns, but I urged him share his work with the rest of the team. He eventually did - and everyone benefited. The team became more productive, and the toolsmith got a nicer bonus at the end of the year, and the appreciation of the team.
You might find that your boss would welcome this approach. Or you might find that she/he would rather you not share.
answered Nov 4 '15 at 21:38
Joe Strazzere
223k104651918
How can I safely share these utilities without putting myself in harms
way?
Talk with your manager, and explain your dilemma.
Suggest that you be given permission and time to enhance your utilities so that they are more robust, have a sufficient level of error handling, are well documented, and are well-tested on machines other than yours. Then, you could present the enhanced utilities to the team for their use.
As @cbojar wisely suggests, if your team has an internal tools person or group - you could turn the finished product over to them for continued support.
I was fortunate enough to have a terrific "toolsmith" on my last QA Team. He was a wiz at creating these sorts of tools, tips, and utilities. He shared your concerns, but I urged him share his work with the rest of the team. He eventually did - and everyone benefited. The team became more productive, and the toolsmith got a nicer bonus at the end of the year, and the appreciation of the team.
You might find that your boss would welcome this approach. Or you might find that she/he would rather you not share.
answered Nov 4 '15 at 21:38
Joe Strazzere
223k104651918
edited Nov 4 '15 at 22:47
answered Nov 4 '15 at 21:38
Joe Strazzere
223k104651918
answered Nov 4 '15 at 21:38
Joe Strazzere
223k104651918
answered Nov 4 '15 at 21:38
Joe Strazzere
223k104651918
223k104651918
5
If the OP's company has an internal tools team, they may even be able to hand off maintenance of the scripts to someone else.
– cbojar
Nov 4 '15 at 21:43
1
Also, don't neglect to QA the tools. Make them a real "product". Not that I've ever had to track down a bug that was in a tool QA was using instead of my package. grumble.
– ColleenV
Nov 4 '15 at 21:56
1
+1 for manager approval. You'll need higher up backings before you start running off and doing tool testing on your colleague's computers. I was in a similar situation in a call center, and I created tools that provided a huge productivity boost to everyone, but I had to spend time to troubleshoot the tools, and also add in different ways of triggering them since everyone are not me.
– Nelson
Nov 5 '15 at 0:44
1
If I understood this right, you are suggesting that the OP should take on developing and supporting these tools. That can be a lot of work in itself, and lead to a shift in the type of work he is doing. He may not be willing to do this, not just because of the issue of taking on responsibility, but simply because it's not the kind of work he signed up for. I know I wouldn't want to do it. But then I'm in academia so I don't really know how things work at companies.
– Szabolcs
Nov 5 '15 at 11:01
suggest improvements |Â
5
If the OP's company has an internal tools team, they may even be able to hand off maintenance of the scripts to someone else.
– cbojar
Nov 4 '15 at 21:43
1
Also, don't neglect to QA the tools. Make them a real "product". Not that I've ever had to track down a bug that was in a tool QA was using instead of my package. grumble.
– ColleenV
Nov 4 '15 at 21:56
1
+1 for manager approval. You'll need higher up backings before you start running off and doing tool testing on your colleague's computers. I was in a similar situation in a call center, and I created tools that provided a huge productivity boost to everyone, but I had to spend time to troubleshoot the tools, and also add in different ways of triggering them since everyone are not me.
– Nelson
Nov 5 '15 at 0:44
1
If I understood this right, you are suggesting that the OP should take on developing and supporting these tools. That can be a lot of work in itself, and lead to a shift in the type of work he is doing. He may not be willing to do this, not just because of the issue of taking on responsibility, but simply because it's not the kind of work he signed up for. I know I wouldn't want to do it. But then I'm in academia so I don't really know how things work at companies.
– Szabolcs
Nov 5 '15 at 11:01
5
5
If the OP's company has an internal tools team, they may even be able to hand off maintenance of the scripts to someone else.
– cbojar
Nov 4 '15 at 21:43
If the OP's company has an internal tools team, they may even be able to hand off maintenance of the scripts to someone else.
– cbojar
Nov 4 '15 at 21:43
1
1
Also, don't neglect to QA the tools. Make them a real "product". Not that I've ever had to track down a bug that was in a tool QA was using instead of my package. grumble.
– ColleenV
Nov 4 '15 at 21:56
Also, don't neglect to QA the tools. Make them a real "product". Not that I've ever had to track down a bug that was in a tool QA was using instead of my package. grumble.
– ColleenV
Nov 4 '15 at 21:56
1
1
+1 for manager approval. You'll need higher up backings before you start running off and doing tool testing on your colleague's computers. I was in a similar situation in a call center, and I created tools that provided a huge productivity boost to everyone, but I had to spend time to troubleshoot the tools, and also add in different ways of triggering them since everyone are not me.
– Nelson
Nov 5 '15 at 0:44
+1 for manager approval. You'll need higher up backings before you start running off and doing tool testing on your colleague's computers. I was in a similar situation in a call center, and I created tools that provided a huge productivity boost to everyone, but I had to spend time to troubleshoot the tools, and also add in different ways of triggering them since everyone are not me.
– Nelson
Nov 5 '15 at 0:44
1
1
If I understood this right, you are suggesting that the OP should take on developing and supporting these tools. That can be a lot of work in itself, and lead to a shift in the type of work he is doing. He may not be willing to do this, not just because of the issue of taking on responsibility, but simply because it's not the kind of work he signed up for. I know I wouldn't want to do it. But then I'm in academia so I don't really know how things work at companies.
– Szabolcs
Nov 5 '15 at 11:01
If I understood this right, you are suggesting that the OP should take on developing and supporting these tools. That can be a lot of work in itself, and lead to a shift in the type of work he is doing. He may not be willing to do this, not just because of the issue of taking on responsibility, but simply because it's not the kind of work he signed up for. I know I wouldn't want to do it. But then I'm in academia so I don't really know how things work at companies.
– Szabolcs
Nov 5 '15 at 11:01
suggest improvements |Â
up vote
7
down vote
You are using these tools to make your job easier and your coworkers have seen that. That means they all have a need for it, or are even unhappy with the situation they face at work.
I think you should talk to your team lead or manager about this. Be prepared, show them the benefits of the automated approach and how it frees up time for other things, like actual testing. Then let them decide. A good manager will see how this can increase the efficiency of the team.
If you repeat the same tedious setup process every day and it takes five minutes, then investing 20 minutes to automate it will amortize after less than a week. In fact, it saves an hour of work for a team of five every week. It's also less error-prone if it is automated because you cannot accidentally click the wrong stuff because it's boring time consuming clicking and waiting.
This XKCD comic explains in an easy way when automation of tasks makes sense.
You can suggest that you can maintain and improve the things for the whole team. Move them from your desktop to a company git and let everyone benefit. That's in the company's interest and your manager will likely be happy to give you time to further improve if properly convinced. Hard facts can go a long way even for the most untechnical manager.
answered Nov 4 '15 at 21:47
simbabque
3,13911022
suggest improvements |Â
up vote
7
down vote
You are using these tools to make your job easier and your coworkers have seen that. That means they all have a need for it, or are even unhappy with the situation they face at work.
I think you should talk to your team lead or manager about this. Be prepared, show them the benefits of the automated approach and how it frees up time for other things, like actual testing. Then let them decide. A good manager will see how this can increase the efficiency of the team.
If you repeat the same tedious setup process every day and it takes five minutes, then investing 20 minutes to automate it will amortize after less than a week. In fact, it saves an hour of work for a team of five every week. It's also less error-prone if it is automated because you cannot accidentally click the wrong stuff because it's boring time consuming clicking and waiting.
This XKCD comic explains in an easy way when automation of tasks makes sense.
You can suggest that you can maintain and improve the things for the whole team. Move them from your desktop to a company git and let everyone benefit. That's in the company's interest and your manager will likely be happy to give you time to further improve if properly convinced. Hard facts can go a long way even for the most untechnical manager.
answered Nov 4 '15 at 21:47
simbabque
3,13911022
suggest improvements |Â
up vote
7
down vote
up vote
7
down vote
You are using these tools to make your job easier and your coworkers have seen that. That means they all have a need for it, or are even unhappy with the situation they face at work.
I think you should talk to your team lead or manager about this. Be prepared, show them the benefits of the automated approach and how it frees up time for other things, like actual testing. Then let them decide. A good manager will see how this can increase the efficiency of the team.
If you repeat the same tedious setup process every day and it takes five minutes, then investing 20 minutes to automate it will amortize after less than a week. In fact, it saves an hour of work for a team of five every week. It's also less error-prone if it is automated because you cannot accidentally click the wrong stuff because it's boring time consuming clicking and waiting.
This XKCD comic explains in an easy way when automation of tasks makes sense.
You can suggest that you can maintain and improve the things for the whole team. Move them from your desktop to a company git and let everyone benefit. That's in the company's interest and your manager will likely be happy to give you time to further improve if properly convinced. Hard facts can go a long way even for the most untechnical manager.
answered Nov 4 '15 at 21:47
simbabque
3,13911022
You are using these tools to make your job easier and your coworkers have seen that. That means they all have a need for it, or are even unhappy with the situation they face at work.
I think you should talk to your team lead or manager about this. Be prepared, show them the benefits of the automated approach and how it frees up time for other things, like actual testing. Then let them decide. A good manager will see how this can increase the efficiency of the team.
If you repeat the same tedious setup process every day and it takes five minutes, then investing 20 minutes to automate it will amortize after less than a week. In fact, it saves an hour of work for a team of five every week. It's also less error-prone if it is automated because you cannot accidentally click the wrong stuff because it's boring time consuming clicking and waiting.
This XKCD comic explains in an easy way when automation of tasks makes sense.
You can suggest that you can maintain and improve the things for the whole team. Move them from your desktop to a company git and let everyone benefit. That's in the company's interest and your manager will likely be happy to give you time to further improve if properly convinced. Hard facts can go a long way even for the most untechnical manager.
answered Nov 4 '15 at 21:47
simbabque
3,13911022
edited Dec 5 '17 at 10:51
answered Nov 4 '15 at 21:47
simbabque
3,13911022
answered Nov 4 '15 at 21:47
simbabque
3,13911022
answered Nov 4 '15 at 21:47
simbabque
3,13911022
3,13911022
suggest improvements |Â
suggest improvements |Â
up vote
3
down vote
First, creating tools can make you very valuable to your team and employer. You need to gauge the effectiveness of your tools and make your decision based on that. For me, I once developed a reporting system that turned 2 hours of work into 5 seconds of work--and no more missed deadlines.
If you're worried about damaging something, I'd suggest to work that out before releasing anything to your coworkers. You'll need to make this decision after weighing risks.
For me, usually there are little to no risks involved in my scripts and tools. I usually provide them with an AS-IS disclaimer and provide no support. However, it's gotten to the point that I'm formally asked to fix or maintain certain tools that improve workplace productivity.
Finally, if you do have an internal team, it's great to engage them with your work. This can help prevent code rot. In my case, I added a birthday reminder to one of my tools. After getting laid-off and shortly after my next birthday, I was asked to cover for someone on extended leave. I found out, the team maintaining my code had recommended me because they had worked with my code recently.
answered Nov 5 '15 at 1:10
Nathan Goings
27917
suggest improvements |Â
up vote
3
down vote
First, creating tools can make you very valuable to your team and employer. You need to gauge the effectiveness of your tools and make your decision based on that. For me, I once developed a reporting system that turned 2 hours of work into 5 seconds of work--and no more missed deadlines.
If you're worried about damaging something, I'd suggest to work that out before releasing anything to your coworkers. You'll need to make this decision after weighing risks.
For me, usually there are little to no risks involved in my scripts and tools. I usually provide them with an AS-IS disclaimer and provide no support. However, it's gotten to the point that I'm formally asked to fix or maintain certain tools that improve workplace productivity.
Finally, if you do have an internal team, it's great to engage them with your work. This can help prevent code rot. In my case, I added a birthday reminder to one of my tools. After getting laid-off and shortly after my next birthday, I was asked to cover for someone on extended leave. I found out, the team maintaining my code had recommended me because they had worked with my code recently.
answered Nov 5 '15 at 1:10
Nathan Goings
27917
suggest improvements |Â
up vote
3
down vote
up vote
3
down vote
First, creating tools can make you very valuable to your team and employer. You need to gauge the effectiveness of your tools and make your decision based on that. For me, I once developed a reporting system that turned 2 hours of work into 5 seconds of work--and no more missed deadlines.
If you're worried about damaging something, I'd suggest to work that out before releasing anything to your coworkers. You'll need to make this decision after weighing risks.
For me, usually there are little to no risks involved in my scripts and tools. I usually provide them with an AS-IS disclaimer and provide no support. However, it's gotten to the point that I'm formally asked to fix or maintain certain tools that improve workplace productivity.
Finally, if you do have an internal team, it's great to engage them with your work. This can help prevent code rot. In my case, I added a birthday reminder to one of my tools. After getting laid-off and shortly after my next birthday, I was asked to cover for someone on extended leave. I found out, the team maintaining my code had recommended me because they had worked with my code recently.
answered Nov 5 '15 at 1:10
Nathan Goings
27917
First, creating tools can make you very valuable to your team and employer. You need to gauge the effectiveness of your tools and make your decision based on that. For me, I once developed a reporting system that turned 2 hours of work into 5 seconds of work--and no more missed deadlines.
If you're worried about damaging something, I'd suggest to work that out before releasing anything to your coworkers. You'll need to make this decision after weighing risks.
For me, usually there are little to no risks involved in my scripts and tools. I usually provide them with an AS-IS disclaimer and provide no support. However, it's gotten to the point that I'm formally asked to fix or maintain certain tools that improve workplace productivity.
Finally, if you do have an internal team, it's great to engage them with your work. This can help prevent code rot. In my case, I added a birthday reminder to one of my tools. After getting laid-off and shortly after my next birthday, I was asked to cover for someone on extended leave. I found out, the team maintaining my code had recommended me because they had worked with my code recently.
answered Nov 5 '15 at 1:10
Nathan Goings
27917
answered Nov 5 '15 at 1:10
Nathan Goings
27917
answered Nov 5 '15 at 1:10
Nathan Goings
27917
answered Nov 5 '15 at 1:10
Nathan Goings
27917
27917
suggest improvements |Â
suggest improvements |Â
up vote
2
down vote
I think you are making a mountain out of a molehill. Sharing off-the-cuff project specific tools and scripts happens frequently in the development world. Quite frankly, any software developer who isn't often creating their own productivity enhancement "tools" is almost certainly not going to be a very good developer. When developers share these types of tools then everyone knows what they are getting.
What is more likely to happen versus getting blamed is if it turns out that your tool really is useful then the source code/scripts will be added to the software CM system and then the developers will all start adding their desired features. One day your rather mundane tool may blossom into a quite slick application that is a core part of the project's (or even company) development process.
If people ask you to "support" the tools then you just be honest and tell them "I only created the tool for my personal use. I can give you the source code and you can modify it to your liking if it doesn't do what you want". Very simple, you don't end up owning the tools simply because you wrote them and others want to use them.
answered Nov 5 '15 at 18:35
Dunk
1,10278
suggest improvements |Â
up vote
2
down vote
I think you are making a mountain out of a molehill. Sharing off-the-cuff project specific tools and scripts happens frequently in the development world. Quite frankly, any software developer who isn't often creating their own productivity enhancement "tools" is almost certainly not going to be a very good developer. When developers share these types of tools then everyone knows what they are getting.
What is more likely to happen versus getting blamed is if it turns out that your tool really is useful then the source code/scripts will be added to the software CM system and then the developers will all start adding their desired features. One day your rather mundane tool may blossom into a quite slick application that is a core part of the project's (or even company) development process.
If people ask you to "support" the tools then you just be honest and tell them "I only created the tool for my personal use. I can give you the source code and you can modify it to your liking if it doesn't do what you want". Very simple, you don't end up owning the tools simply because you wrote them and others want to use them.
answered Nov 5 '15 at 18:35
Dunk
1,10278
suggest improvements |Â
up vote
2
down vote
up vote
2
down vote
I think you are making a mountain out of a molehill. Sharing off-the-cuff project specific tools and scripts happens frequently in the development world. Quite frankly, any software developer who isn't often creating their own productivity enhancement "tools" is almost certainly not going to be a very good developer. When developers share these types of tools then everyone knows what they are getting.
What is more likely to happen versus getting blamed is if it turns out that your tool really is useful then the source code/scripts will be added to the software CM system and then the developers will all start adding their desired features. One day your rather mundane tool may blossom into a quite slick application that is a core part of the project's (or even company) development process.
If people ask you to "support" the tools then you just be honest and tell them "I only created the tool for my personal use. I can give you the source code and you can modify it to your liking if it doesn't do what you want". Very simple, you don't end up owning the tools simply because you wrote them and others want to use them.
answered Nov 5 '15 at 18:35
Dunk
1,10278
I think you are making a mountain out of a molehill. Sharing off-the-cuff project specific tools and scripts happens frequently in the development world. Quite frankly, any software developer who isn't often creating their own productivity enhancement "tools" is almost certainly not going to be a very good developer. When developers share these types of tools then everyone knows what they are getting.
What is more likely to happen versus getting blamed is if it turns out that your tool really is useful then the source code/scripts will be added to the software CM system and then the developers will all start adding their desired features. One day your rather mundane tool may blossom into a quite slick application that is a core part of the project's (or even company) development process.
If people ask you to "support" the tools then you just be honest and tell them "I only created the tool for my personal use. I can give you the source code and you can modify it to your liking if it doesn't do what you want". Very simple, you don't end up owning the tools simply because you wrote them and others want to use them.
answered Nov 5 '15 at 18:35
Dunk
1,10278
edited Nov 5 '15 at 18:41
answered Nov 5 '15 at 18:35
Dunk
1,10278
answered Nov 5 '15 at 18:35
Dunk
1,10278
answered Nov 5 '15 at 18:35
Dunk
1,10278
1,10278
suggest improvements |Â
suggest improvements |Â
up vote
0
down vote
One way to address the support issue is to make these tools a company-internal open source, peer-supported project. That lets others get involved in fixing the bugs rather than uour having to bear all that burden. Downside is that you'd be giving up some degree of control over the code, and in accepting their fixes you also run the risk of those creating new bugs.... but if you can't confince management to pay you for time spent polishing these tools, this is probably the best way to share both costs and benefits, and it lets you pick other programmers' brains for solutions to tough problems.
answered Nov 5 '15 at 19:29
keshlam
41.5k1267144
suggest improvements |Â
up vote
0
down vote
One way to address the support issue is to make these tools a company-internal open source, peer-supported project. That lets others get involved in fixing the bugs rather than uour having to bear all that burden. Downside is that you'd be giving up some degree of control over the code, and in accepting their fixes you also run the risk of those creating new bugs.... but if you can't confince management to pay you for time spent polishing these tools, this is probably the best way to share both costs and benefits, and it lets you pick other programmers' brains for solutions to tough problems.
answered Nov 5 '15 at 19:29
keshlam
41.5k1267144
suggest improvements |Â
up vote
0
down vote
up vote
0
down vote
One way to address the support issue is to make these tools a company-internal open source, peer-supported project. That lets others get involved in fixing the bugs rather than uour having to bear all that burden. Downside is that you'd be giving up some degree of control over the code, and in accepting their fixes you also run the risk of those creating new bugs.... but if you can't confince management to pay you for time spent polishing these tools, this is probably the best way to share both costs and benefits, and it lets you pick other programmers' brains for solutions to tough problems.
answered Nov 5 '15 at 19:29
keshlam
41.5k1267144
One way to address the support issue is to make these tools a company-internal open source, peer-supported project. That lets others get involved in fixing the bugs rather than uour having to bear all that burden. Downside is that you'd be giving up some degree of control over the code, and in accepting their fixes you also run the risk of those creating new bugs.... but if you can't confince management to pay you for time spent polishing these tools, this is probably the best way to share both costs and benefits, and it lets you pick other programmers' brains for solutions to tough problems.
answered Nov 5 '15 at 19:29
keshlam
41.5k1267144
answered Nov 5 '15 at 19:29
keshlam
41.5k1267144
answered Nov 5 '15 at 19:29
keshlam
41.5k1267144
answered Nov 5 '15 at 19:29
keshlam
41.5k1267144
41.5k1267144
suggest improvements |Â
suggest improvements |Â
up vote
-3
down vote
As a software developer I too had the same problem. I think there's a very simple and easy way for you to handle this:
Upload your tools, frameworks, utilities to GitHub with an appropriate license. For example I've used the MIT license that has following text:
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
I cannot give legal advice, so check what license works best for you yourself.
And giving the link to the tool you can specify something like alpha or beta version - that usually gives a pretty good hint that the software can have bugs or missing features.
That should negate any tension in case if your tool doesn't work as intended. At least legally.
If asked to make updates to the tool from a college - tell that you do that in your free time and can't promise any deadlines. If asked from a manager - make a fork and continue the development.
answered Nov 5 '15 at 2:50
test
46329
6
This would likely open you up to intellectual property suites since you created these products on company time. I suggest not following this advice without first speaking with your manager.
– Brandon
Nov 5 '15 at 2:52
That should negate any tension in case if your tool doesn't work as intended. At least legally.Are you really worried about the person sitting next to you at work personally suing you for damages because of an implied warranty? That must be a dangerous script. If I could sue for damages every time I observed a software bug, I'd be a wealthy man.
– Brandon
Nov 5 '15 at 2:55
1
@Brandon You are wrong, if you're going to develop the tool during company time - you're making a fork ( a clone ), from that point onward it's not your copy of code - it's companies copy. And you are wrong again about person next to you suing you - the person next to you would point a finger at you saying the tool caused a problem. The company(!) could sue you for damages. And could doesn't mean will. And you are wrong the third time about script needing to be dangerous - it could be simply a bug that would corrupt the format of a file and thus - a lot of work needing to be remade.
– test
Nov 5 '15 at 3:51
suggest improvements |Â
up vote
-3
down vote
As a software developer I too had the same problem. I think there's a very simple and easy way for you to handle this:
Upload your tools, frameworks, utilities to GitHub with an appropriate license. For example I've used the MIT license that has following text:
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
I cannot give legal advice, so check what license works best for you yourself.
And giving the link to the tool you can specify something like alpha or beta version - that usually gives a pretty good hint that the software can have bugs or missing features.
That should negate any tension in case if your tool doesn't work as intended. At least legally.
If asked to make updates to the tool from a college - tell that you do that in your free time and can't promise any deadlines. If asked from a manager - make a fork and continue the development.
answered Nov 5 '15 at 2:50
test
46329
6
This would likely open you up to intellectual property suites since you created these products on company time. I suggest not following this advice without first speaking with your manager.
– Brandon
Nov 5 '15 at 2:52
That should negate any tension in case if your tool doesn't work as intended. At least legally.Are you really worried about the person sitting next to you at work personally suing you for damages because of an implied warranty? That must be a dangerous script. If I could sue for damages every time I observed a software bug, I'd be a wealthy man.
– Brandon
Nov 5 '15 at 2:55
1
@Brandon You are wrong, if you're going to develop the tool during company time - you're making a fork ( a clone ), from that point onward it's not your copy of code - it's companies copy. And you are wrong again about person next to you suing you - the person next to you would point a finger at you saying the tool caused a problem. The company(!) could sue you for damages. And could doesn't mean will. And you are wrong the third time about script needing to be dangerous - it could be simply a bug that would corrupt the format of a file and thus - a lot of work needing to be remade.
– test
Nov 5 '15 at 3:51
suggest improvements |Â
up vote
-3
down vote
up vote
-3
down vote
As a software developer I too had the same problem. I think there's a very simple and easy way for you to handle this:
Upload your tools, frameworks, utilities to GitHub with an appropriate license. For example I've used the MIT license that has following text:
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
I cannot give legal advice, so check what license works best for you yourself.
And giving the link to the tool you can specify something like alpha or beta version - that usually gives a pretty good hint that the software can have bugs or missing features.
That should negate any tension in case if your tool doesn't work as intended. At least legally.
If asked to make updates to the tool from a college - tell that you do that in your free time and can't promise any deadlines. If asked from a manager - make a fork and continue the development.
answered Nov 5 '15 at 2:50
test
46329
As a software developer I too had the same problem. I think there's a very simple and easy way for you to handle this:
Upload your tools, frameworks, utilities to GitHub with an appropriate license. For example I've used the MIT license that has following text:
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
I cannot give legal advice, so check what license works best for you yourself.
And giving the link to the tool you can specify something like alpha or beta version - that usually gives a pretty good hint that the software can have bugs or missing features.
That should negate any tension in case if your tool doesn't work as intended. At least legally.
If asked to make updates to the tool from a college - tell that you do that in your free time and can't promise any deadlines. If asked from a manager - make a fork and continue the development.
answered Nov 5 '15 at 2:50
test
46329
answered Nov 5 '15 at 2:50
test
46329
answered Nov 5 '15 at 2:50
test
46329
answered Nov 5 '15 at 2:50
test
46329
46329
6
This would likely open you up to intellectual property suites since you created these products on company time. I suggest not following this advice without first speaking with your manager.
– Brandon
Nov 5 '15 at 2:52
That should negate any tension in case if your tool doesn't work as intended. At least legally.Are you really worried about the person sitting next to you at work personally suing you for damages because of an implied warranty? That must be a dangerous script. If I could sue for damages every time I observed a software bug, I'd be a wealthy man.
– Brandon
Nov 5 '15 at 2:55
1
@Brandon You are wrong, if you're going to develop the tool during company time - you're making a fork ( a clone ), from that point onward it's not your copy of code - it's companies copy. And you are wrong again about person next to you suing you - the person next to you would point a finger at you saying the tool caused a problem. The company(!) could sue you for damages. And could doesn't mean will. And you are wrong the third time about script needing to be dangerous - it could be simply a bug that would corrupt the format of a file and thus - a lot of work needing to be remade.
– test
Nov 5 '15 at 3:51
suggest improvements |Â
6
This would likely open you up to intellectual property suites since you created these products on company time. I suggest not following this advice without first speaking with your manager.
– Brandon
Nov 5 '15 at 2:52
That should negate any tension in case if your tool doesn't work as intended. At least legally.Are you really worried about the person sitting next to you at work personally suing you for damages because of an implied warranty? That must be a dangerous script. If I could sue for damages every time I observed a software bug, I'd be a wealthy man.
– Brandon
Nov 5 '15 at 2:55
1
@Brandon You are wrong, if you're going to develop the tool during company time - you're making a fork ( a clone ), from that point onward it's not your copy of code - it's companies copy. And you are wrong again about person next to you suing you - the person next to you would point a finger at you saying the tool caused a problem. The company(!) could sue you for damages. And could doesn't mean will. And you are wrong the third time about script needing to be dangerous - it could be simply a bug that would corrupt the format of a file and thus - a lot of work needing to be remade.
– test
Nov 5 '15 at 3:51
6
6
This would likely open you up to intellectual property suites since you created these products on company time. I suggest not following this advice without first speaking with your manager.
– Brandon
Nov 5 '15 at 2:52
This would likely open you up to intellectual property suites since you created these products on company time. I suggest not following this advice without first speaking with your manager.
– Brandon
Nov 5 '15 at 2:52
That should negate any tension in case if your tool doesn't work as intended. At least legally. Are you really worried about the person sitting next to you at work personally suing you for damages because of an implied warranty? That must be a dangerous script. If I could sue for damages every time I observed a software bug, I'd be a wealthy man.– Brandon
Nov 5 '15 at 2:55
That should negate any tension in case if your tool doesn't work as intended. At least legally. Are you really worried about the person sitting next to you at work personally suing you for damages because of an implied warranty? That must be a dangerous script. If I could sue for damages every time I observed a software bug, I'd be a wealthy man.– Brandon
Nov 5 '15 at 2:55
1
1
@Brandon You are wrong, if you're going to develop the tool during company time - you're making a fork ( a clone ), from that point onward it's not your copy of code - it's companies copy. And you are wrong again about person next to you suing you - the person next to you would point a finger at you saying the tool caused a problem. The company(!) could sue you for damages. And could doesn't mean will. And you are wrong the third time about script needing to be dangerous - it could be simply a bug that would corrupt the format of a file and thus - a lot of work needing to be remade.
– test
Nov 5 '15 at 3:51
@Brandon You are wrong, if you're going to develop the tool during company time - you're making a fork ( a clone ), from that point onward it's not your copy of code - it's companies copy. And you are wrong again about person next to you suing you - the person next to you would point a finger at you saying the tool caused a problem. The company(!) could sue you for damages. And could doesn't mean will. And you are wrong the third time about script needing to be dangerous - it could be simply a bug that would corrupt the format of a file and thus - a lot of work needing to be remade.
– test
Nov 5 '15 at 3:51
suggest improvements |Â
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
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f57181%2fsharing-self-developed-but-untested-tools-or-processes-with-colleagues%23new-answer', 'question_page');
);
Post as a guest
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
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
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
5
@JaneS I'm not so sure. I could just as easily replace the premise with "I found a great new way to skin a cat, but it hasn't been put through peer review, and I can't gaurentee it will work in 100% of cases"
– Sidney
Nov 4 '15 at 21:34
16
If your employer looks negatively upon you creating things that let you do your job better, faster & more efficiently, you ought to find a new place to work that will appreciate your efforts.
– alroc
Nov 4 '15 at 21:39
6
Sell the company your toolkit, then everyone wins
– Kilisi
Nov 4 '15 at 21:51
1
"possibly implicating me in damages". That's complete bull. For starters, you developed these on work time, so you don't own them, your company does. If your coworkers are doing the same job as you, they also have the skills to fix bugs in them. If you want to be proactive, you could suggest to your line manager that you share them and that you want to allow a couple of hours a week for fixing things that people find. No sane manager will knock back someone trying to improve their team's productivity.
– Graham
Nov 5 '15 at 10:45
3
Voted to reopen. I've retitled this post, reformulated your core question and expanded it with a few other questions to detail what you're trying to accomplish (and avoid this being off-topic as a generic advice question). While this question is (still) not perfect, I frankly don't get why this was closed as company-specific.
– Lilienthal♦
Nov 5 '15 at 12:08