Mixing
Work being cut out
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
0
down vote
favorite
I am a programmer working for a manufacturing company which I've been with for 15 yrs. I am part of two large in house projects for which I have been developing the underlying framework.
Lately I have had large potions of the framework cut out because "this isn't the way we have always done it."
My question is : Am I being too sensitive by letting this bother me?
This has me feeling like I'm not really a member of the team. While my supervisor tells me that my work is top notch, and he likes the new things I have added, I find that it just doesn't seem meaningful to me at this point. I still really love the work, but am not sure about continuing at this company.
First let me say I apologize for not having a clearer question, I haven't done this before. My situation is a part of an in house dev team. Our users are all part of the same company or it reps. We are in the process of developing a new tool the engineers will use in support of a new product. The design of this tool will look to the user to be very similar to an existing one. My part is the framework, file support and general low level functions. There is something of a shift involved for the devs. The previous app was all objects and xml files. The new one is database driven. Its a bit of a change but not that much. Here's one example : I was given a requirement to support Undo/Redo. I have delivered that. As part of this process the process of opening a form is slightly different. One of the Devs doesn't like that and now suddenly the requirement for Undo is no longer needed. No discussion of the pros/cons just out. My supervisor just goes along with this and tells me in private how much he likes the new way things are being done. This sort of thing has been happening right along and I'm just wondering how others deal with this.
Thanks for all the replies, It really already helps.
professionalism work-environment
asked Nov 30 '15 at 19:25
Lauren
1072
suggest improvements |Â
up vote
0
down vote
favorite
I am a programmer working for a manufacturing company which I've been with for 15 yrs. I am part of two large in house projects for which I have been developing the underlying framework.
Lately I have had large potions of the framework cut out because "this isn't the way we have always done it."
My question is : Am I being too sensitive by letting this bother me?
This has me feeling like I'm not really a member of the team. While my supervisor tells me that my work is top notch, and he likes the new things I have added, I find that it just doesn't seem meaningful to me at this point. I still really love the work, but am not sure about continuing at this company.
First let me say I apologize for not having a clearer question, I haven't done this before. My situation is a part of an in house dev team. Our users are all part of the same company or it reps. We are in the process of developing a new tool the engineers will use in support of a new product. The design of this tool will look to the user to be very similar to an existing one. My part is the framework, file support and general low level functions. There is something of a shift involved for the devs. The previous app was all objects and xml files. The new one is database driven. Its a bit of a change but not that much. Here's one example : I was given a requirement to support Undo/Redo. I have delivered that. As part of this process the process of opening a form is slightly different. One of the Devs doesn't like that and now suddenly the requirement for Undo is no longer needed. No discussion of the pros/cons just out. My supervisor just goes along with this and tells me in private how much he likes the new way things are being done. This sort of thing has been happening right along and I'm just wondering how others deal with this.
Thanks for all the replies, It really already helps.
professionalism work-environment
asked Nov 30 '15 at 19:25
Lauren
1072
Is this the company you have worked for for 15 years saying "this is not the way we have always done things", or a customer?
– DJClayworth
Nov 30 '15 at 20:31
1
Hi Lauren. As your question stands, it's asking for people's opinions, which is going to get it closed. I would suggest providing more details: Is this an internal project which you're developing for in-house users, or for external ones? Who's giving you the "it's not the way we do things" feedback? Does this project represent a paradigm shift of dev techniques or tech for the company? Did you develop the project in isolation, or based on specs determined by speaking with the intended users and management? All of these are vital to us understanding the context of your question.
– AndreiROM
Nov 30 '15 at 20:37
"this isn't the way we have always done it." - another name for this is "company standards" or "company practices". However, as JoeStrazzere points out this is different from removing a requirement. If your users had an undo feature before, and now you've removed it, I personally can't imagine they would accept that. I remember using software before "undo" was the general expectation. But now that it's the norm, it's hard to go back. Nonetheless, if your manager decides it's not needed, that's probably on him.
– Brandin
Dec 1 '15 at 11:35
suggest improvements |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I am a programmer working for a manufacturing company which I've been with for 15 yrs. I am part of two large in house projects for which I have been developing the underlying framework.
Lately I have had large potions of the framework cut out because "this isn't the way we have always done it."
My question is : Am I being too sensitive by letting this bother me?
This has me feeling like I'm not really a member of the team. While my supervisor tells me that my work is top notch, and he likes the new things I have added, I find that it just doesn't seem meaningful to me at this point. I still really love the work, but am not sure about continuing at this company.
First let me say I apologize for not having a clearer question, I haven't done this before. My situation is a part of an in house dev team. Our users are all part of the same company or it reps. We are in the process of developing a new tool the engineers will use in support of a new product. The design of this tool will look to the user to be very similar to an existing one. My part is the framework, file support and general low level functions. There is something of a shift involved for the devs. The previous app was all objects and xml files. The new one is database driven. Its a bit of a change but not that much. Here's one example : I was given a requirement to support Undo/Redo. I have delivered that. As part of this process the process of opening a form is slightly different. One of the Devs doesn't like that and now suddenly the requirement for Undo is no longer needed. No discussion of the pros/cons just out. My supervisor just goes along with this and tells me in private how much he likes the new way things are being done. This sort of thing has been happening right along and I'm just wondering how others deal with this.
Thanks for all the replies, It really already helps.
professionalism work-environment
asked Nov 30 '15 at 19:25
Lauren
1072
I am a programmer working for a manufacturing company which I've been with for 15 yrs. I am part of two large in house projects for which I have been developing the underlying framework.
Lately I have had large potions of the framework cut out because "this isn't the way we have always done it."
My question is : Am I being too sensitive by letting this bother me?
This has me feeling like I'm not really a member of the team. While my supervisor tells me that my work is top notch, and he likes the new things I have added, I find that it just doesn't seem meaningful to me at this point. I still really love the work, but am not sure about continuing at this company.
First let me say I apologize for not having a clearer question, I haven't done this before. My situation is a part of an in house dev team. Our users are all part of the same company or it reps. We are in the process of developing a new tool the engineers will use in support of a new product. The design of this tool will look to the user to be very similar to an existing one. My part is the framework, file support and general low level functions. There is something of a shift involved for the devs. The previous app was all objects and xml files. The new one is database driven. Its a bit of a change but not that much. Here's one example : I was given a requirement to support Undo/Redo. I have delivered that. As part of this process the process of opening a form is slightly different. One of the Devs doesn't like that and now suddenly the requirement for Undo is no longer needed. No discussion of the pros/cons just out. My supervisor just goes along with this and tells me in private how much he likes the new way things are being done. This sort of thing has been happening right along and I'm just wondering how others deal with this.
Thanks for all the replies, It really already helps.
professionalism work-environment
asked Nov 30 '15 at 19:25
Lauren
1072
edited Nov 30 '15 at 21:00
asked Nov 30 '15 at 19:25
Lauren
1072
asked Nov 30 '15 at 19:25
Lauren
1072
asked Nov 30 '15 at 19:25
Lauren
1072
1072
Is this the company you have worked for for 15 years saying "this is not the way we have always done things", or a customer?
– DJClayworth
Nov 30 '15 at 20:31
1
Hi Lauren. As your question stands, it's asking for people's opinions, which is going to get it closed. I would suggest providing more details: Is this an internal project which you're developing for in-house users, or for external ones? Who's giving you the "it's not the way we do things" feedback? Does this project represent a paradigm shift of dev techniques or tech for the company? Did you develop the project in isolation, or based on specs determined by speaking with the intended users and management? All of these are vital to us understanding the context of your question.
– AndreiROM
Nov 30 '15 at 20:37
"this isn't the way we have always done it." - another name for this is "company standards" or "company practices". However, as JoeStrazzere points out this is different from removing a requirement. If your users had an undo feature before, and now you've removed it, I personally can't imagine they would accept that. I remember using software before "undo" was the general expectation. But now that it's the norm, it's hard to go back. Nonetheless, if your manager decides it's not needed, that's probably on him.
– Brandin
Dec 1 '15 at 11:35
suggest improvements |Â
Is this the company you have worked for for 15 years saying "this is not the way we have always done things", or a customer?
– DJClayworth
Nov 30 '15 at 20:31
1
Hi Lauren. As your question stands, it's asking for people's opinions, which is going to get it closed. I would suggest providing more details: Is this an internal project which you're developing for in-house users, or for external ones? Who's giving you the "it's not the way we do things" feedback? Does this project represent a paradigm shift of dev techniques or tech for the company? Did you develop the project in isolation, or based on specs determined by speaking with the intended users and management? All of these are vital to us understanding the context of your question.
– AndreiROM
Nov 30 '15 at 20:37
"this isn't the way we have always done it." - another name for this is "company standards" or "company practices". However, as JoeStrazzere points out this is different from removing a requirement. If your users had an undo feature before, and now you've removed it, I personally can't imagine they would accept that. I remember using software before "undo" was the general expectation. But now that it's the norm, it's hard to go back. Nonetheless, if your manager decides it's not needed, that's probably on him.
– Brandin
Dec 1 '15 at 11:35
Is this the company you have worked for for 15 years saying "this is not the way we have always done things", or a customer?
– DJClayworth
Nov 30 '15 at 20:31
Is this the company you have worked for for 15 years saying "this is not the way we have always done things", or a customer?
– DJClayworth
Nov 30 '15 at 20:31
1
1
Hi Lauren. As your question stands, it's asking for people's opinions, which is going to get it closed. I would suggest providing more details: Is this an internal project which you're developing for in-house users, or for external ones? Who's giving you the "it's not the way we do things" feedback? Does this project represent a paradigm shift of dev techniques or tech for the company? Did you develop the project in isolation, or based on specs determined by speaking with the intended users and management? All of these are vital to us understanding the context of your question.
– AndreiROM
Nov 30 '15 at 20:37
Hi Lauren. As your question stands, it's asking for people's opinions, which is going to get it closed. I would suggest providing more details: Is this an internal project which you're developing for in-house users, or for external ones? Who's giving you the "it's not the way we do things" feedback? Does this project represent a paradigm shift of dev techniques or tech for the company? Did you develop the project in isolation, or based on specs determined by speaking with the intended users and management? All of these are vital to us understanding the context of your question.
– AndreiROM
Nov 30 '15 at 20:37
"this isn't the way we have always done it." - another name for this is "company standards" or "company practices". However, as JoeStrazzere points out this is different from removing a requirement. If your users had an undo feature before, and now you've removed it, I personally can't imagine they would accept that. I remember using software before "undo" was the general expectation. But now that it's the norm, it's hard to go back. Nonetheless, if your manager decides it's not needed, that's probably on him.
– Brandin
Dec 1 '15 at 11:35
"this isn't the way we have always done it." - another name for this is "company standards" or "company practices". However, as JoeStrazzere points out this is different from removing a requirement. If your users had an undo feature before, and now you've removed it, I personally can't imagine they would accept that. I remember using software before "undo" was the general expectation. But now that it's the norm, it's hard to go back. Nonetheless, if your manager decides it's not needed, that's probably on him.
– Brandin
Dec 1 '15 at 11:35
suggest improvements |Â
3 Answers
3
active
oldest
votes
up vote
4
down vote
If you are having portions of the project removed because the users don't want to change how they have always done things, that is not a reflection on your technical abilities. It is commonplace and fairly normal.
It is not clear to me if the people who caused the reduction in scope are users who don't like having a new way to do things or devs who don't want to follow a new programming paradigm. So I will address both.
If you want to improve the possibility of getting new ideas into the software, you need to learn how to sell your ideas. First, it is hard to change people and how they have always done things, It is called resistance to change.
The way to get around the resistance is to find out what the new method will make easier for them, what new things they will be able to do that they couldn't and what current problems the current process has that you are fixing. For instance, if the current process frequently gets timeouts causing the data to not be saved, then people are going to be more easily persuaded to try something new.
But if the current method is working just fine, then why would they want to? In this case, you need to have something major to sell them on that will make the change worth it from their perspective. You must always keep their perspective in mind. Nobody who is not a developer cares if the code is more maintainable or uses a more modern programming language unless you can sell them on the idea of what they gain not what you gain from the change.
This is true even if the users you need to persuade are other developers. Maybe they are uncomfortable with the new methods because they don't understand them or they feel intimidated by something they haven't done before. Even devs need to be sold on using new tools especially in an environment like manufacturing where the devs aren't as willing to be on the cutting edge as say a startup.
All users are people first and have the need to feel comfortable with their work. Psychologically very few people embrace change.
So what you do first is find out from them what the problems with the current system are. It is important to ask the people who are resistant to change directly for their opinion on the current process and how they would improve it. More often than not, what others perceive as the problems are not at all what you might see. Understanding the problems they want solved in the new software will help you build a better solution. it will also give you something to sell your new idea with. Further you may find that the solution that looks good to you is actually more time-consuming and harder to use for them. If I have to process X number of widgets per hour, any process that makes me do more clicks and take longer is a problem even if the underlying software is easier to maintain. Remember, users typically spend their whole day using the software, things that look minor to you can really impact their daily productivity in a negative fashion.
Plus a good part of resistance to change is that they were not consulted on the change and had no input into it. The less input they have into a change, the more people will fight it. This is why it is 100% of the time a bad idea to get requirements only from managers (unless only managers use the system) which is an unfortunately common practice. You (or the Business analyst or whoever gathers the requirements) need to talk to users as well.
The next thing that concerns people is that they know how to do what they are doing now and they are afraid they will get thrown into the ocean with no life jacket with a new system.
You counter this fear by specifying how they are going to be trained on the new system and how the new system will be documented and what help in general they can expect during the learning phase. You also take care not to switch to a new method during critical time periods. You don't change the underlying timekeeping system right before payroll is due for instance. Again yo get this information by asking the users about their deadlines and scheduled for the work, so that you can pick a better time to roll out the new system and get them trained and comfortable in it before the critical deadlines. If the devs are resisting instead of the users, again check the time periods, if the deadlines are tight, and they know they will have a long ramp up to new methods, then now is not the moment.
You also want to talk to the resisters about the advantages of the new way to do things. And do not talk about them from your perspective but from theirs. A dev who is resisting might be more interested to learn the new methods are more attractive in a job market than the old methods. A reminder of some particular problems in the past and how hard they were to solve with the old method and how much easier with the new would also help. A user who is resisting might like to know that there will be fewer times when the system goes down or less bad data to fix later. They might like that it will be easier for them to answer their client's questions or resolve problems.
answered Nov 30 '15 at 20:10
HLGEM
133k25226489
I'm surprised you bothered to answer the question based on its unpolished and unclear state.
– AndreiROM
Nov 30 '15 at 20:40
This is pretty much exactly what I was going to say plus more words!
– blankip
Dec 1 '15 at 11:19
suggest improvements |Â
up vote
1
down vote
This suggests you should have been in touch with your prospective customer base earlier, to make sure everyone agreed on what was and wasn't important. That might have let you get them yo buy in on the new features; at worst you'd have known that any work on those features was for the next customer's benefit and would be ignored by these guys. (Gender not implied.)
They may discover the value of the new features later. Or, as I said, that may not happen until some time in the future.
Don't take it personally. You know you did a good job, your manager knows you did a good job, the customer knows you did a good job ... If the worst thing the other team can find to complain about is that you support features they don't expect to use, you did a great job!
edited Nov 30 '15 at 19:39
JB King
15.1k22957
answered Nov 30 '15 at 19:36
keshlam
41.5k1267144
suggest improvements |Â
up vote
1
down vote
That's the 30% rule. It's not always true, but after years, when you average, you're not far, I think...
30% of the code you write, you'll ditch yourself as irrelevant.
30% of the Ketp code won't ever be deployed, for some reason.
30% of the deployed code will never be used(product that didn't sell, people didn't go to that submenu, whatever).
30% of the used code is gonna be ditched within 2 years.
Etc.....
depending on your domain & firm, it can be more or less. But don't get sentimental with your code. Your heart is gonna be broken too often. Be proud of the small part that survives & thrives.
I did have personal code unused because noone ever subscribed the cats & dogs insurance, undeployed because a technical overhaul made it unusable(3 months of hard work), automated test scripts deployed but never ran because the manamgement module was never built, and many others like that. That's not a problem.
Other parts of my code are still running, and every year, when I'm receiving my bill for my car's insurance, I'm proud to say : "my own code did process this numbers. And It saved 1 full FTE of maintenance compared to the old systems".
Most of the rest disappeared, vanished, takes the dust, or is rarely used. I was payed for it. I didn't steal my pay. It now belongs to them. They do what they want with it.
answered Dec 1 '15 at 11:12
gazzz0x2z
5,93621634
indeed. And then there's the code you wrote but never got to deploy because the customer (or your own company) went bankrupt before it was finished (I've had both happen).
– jwenting
Dec 3 '15 at 6:54
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();
);
);
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
4
down vote
If you are having portions of the project removed because the users don't want to change how they have always done things, that is not a reflection on your technical abilities. It is commonplace and fairly normal.
It is not clear to me if the people who caused the reduction in scope are users who don't like having a new way to do things or devs who don't want to follow a new programming paradigm. So I will address both.
If you want to improve the possibility of getting new ideas into the software, you need to learn how to sell your ideas. First, it is hard to change people and how they have always done things, It is called resistance to change.
The way to get around the resistance is to find out what the new method will make easier for them, what new things they will be able to do that they couldn't and what current problems the current process has that you are fixing. For instance, if the current process frequently gets timeouts causing the data to not be saved, then people are going to be more easily persuaded to try something new.
But if the current method is working just fine, then why would they want to? In this case, you need to have something major to sell them on that will make the change worth it from their perspective. You must always keep their perspective in mind. Nobody who is not a developer cares if the code is more maintainable or uses a more modern programming language unless you can sell them on the idea of what they gain not what you gain from the change.
This is true even if the users you need to persuade are other developers. Maybe they are uncomfortable with the new methods because they don't understand them or they feel intimidated by something they haven't done before. Even devs need to be sold on using new tools especially in an environment like manufacturing where the devs aren't as willing to be on the cutting edge as say a startup.
All users are people first and have the need to feel comfortable with their work. Psychologically very few people embrace change.
So what you do first is find out from them what the problems with the current system are. It is important to ask the people who are resistant to change directly for their opinion on the current process and how they would improve it. More often than not, what others perceive as the problems are not at all what you might see. Understanding the problems they want solved in the new software will help you build a better solution. it will also give you something to sell your new idea with. Further you may find that the solution that looks good to you is actually more time-consuming and harder to use for them. If I have to process X number of widgets per hour, any process that makes me do more clicks and take longer is a problem even if the underlying software is easier to maintain. Remember, users typically spend their whole day using the software, things that look minor to you can really impact their daily productivity in a negative fashion.
Plus a good part of resistance to change is that they were not consulted on the change and had no input into it. The less input they have into a change, the more people will fight it. This is why it is 100% of the time a bad idea to get requirements only from managers (unless only managers use the system) which is an unfortunately common practice. You (or the Business analyst or whoever gathers the requirements) need to talk to users as well.
The next thing that concerns people is that they know how to do what they are doing now and they are afraid they will get thrown into the ocean with no life jacket with a new system.
You counter this fear by specifying how they are going to be trained on the new system and how the new system will be documented and what help in general they can expect during the learning phase. You also take care not to switch to a new method during critical time periods. You don't change the underlying timekeeping system right before payroll is due for instance. Again yo get this information by asking the users about their deadlines and scheduled for the work, so that you can pick a better time to roll out the new system and get them trained and comfortable in it before the critical deadlines. If the devs are resisting instead of the users, again check the time periods, if the deadlines are tight, and they know they will have a long ramp up to new methods, then now is not the moment.
You also want to talk to the resisters about the advantages of the new way to do things. And do not talk about them from your perspective but from theirs. A dev who is resisting might be more interested to learn the new methods are more attractive in a job market than the old methods. A reminder of some particular problems in the past and how hard they were to solve with the old method and how much easier with the new would also help. A user who is resisting might like to know that there will be fewer times when the system goes down or less bad data to fix later. They might like that it will be easier for them to answer their client's questions or resolve problems.
answered Nov 30 '15 at 20:10
HLGEM
133k25226489
I'm surprised you bothered to answer the question based on its unpolished and unclear state.
– AndreiROM
Nov 30 '15 at 20:40
This is pretty much exactly what I was going to say plus more words!
– blankip
Dec 1 '15 at 11:19
suggest improvements |Â
up vote
4
down vote
If you are having portions of the project removed because the users don't want to change how they have always done things, that is not a reflection on your technical abilities. It is commonplace and fairly normal.
It is not clear to me if the people who caused the reduction in scope are users who don't like having a new way to do things or devs who don't want to follow a new programming paradigm. So I will address both.
If you want to improve the possibility of getting new ideas into the software, you need to learn how to sell your ideas. First, it is hard to change people and how they have always done things, It is called resistance to change.
The way to get around the resistance is to find out what the new method will make easier for them, what new things they will be able to do that they couldn't and what current problems the current process has that you are fixing. For instance, if the current process frequently gets timeouts causing the data to not be saved, then people are going to be more easily persuaded to try something new.
But if the current method is working just fine, then why would they want to? In this case, you need to have something major to sell them on that will make the change worth it from their perspective. You must always keep their perspective in mind. Nobody who is not a developer cares if the code is more maintainable or uses a more modern programming language unless you can sell them on the idea of what they gain not what you gain from the change.
This is true even if the users you need to persuade are other developers. Maybe they are uncomfortable with the new methods because they don't understand them or they feel intimidated by something they haven't done before. Even devs need to be sold on using new tools especially in an environment like manufacturing where the devs aren't as willing to be on the cutting edge as say a startup.
All users are people first and have the need to feel comfortable with their work. Psychologically very few people embrace change.
So what you do first is find out from them what the problems with the current system are. It is important to ask the people who are resistant to change directly for their opinion on the current process and how they would improve it. More often than not, what others perceive as the problems are not at all what you might see. Understanding the problems they want solved in the new software will help you build a better solution. it will also give you something to sell your new idea with. Further you may find that the solution that looks good to you is actually more time-consuming and harder to use for them. If I have to process X number of widgets per hour, any process that makes me do more clicks and take longer is a problem even if the underlying software is easier to maintain. Remember, users typically spend their whole day using the software, things that look minor to you can really impact their daily productivity in a negative fashion.
Plus a good part of resistance to change is that they were not consulted on the change and had no input into it. The less input they have into a change, the more people will fight it. This is why it is 100% of the time a bad idea to get requirements only from managers (unless only managers use the system) which is an unfortunately common practice. You (or the Business analyst or whoever gathers the requirements) need to talk to users as well.
The next thing that concerns people is that they know how to do what they are doing now and they are afraid they will get thrown into the ocean with no life jacket with a new system.
You counter this fear by specifying how they are going to be trained on the new system and how the new system will be documented and what help in general they can expect during the learning phase. You also take care not to switch to a new method during critical time periods. You don't change the underlying timekeeping system right before payroll is due for instance. Again yo get this information by asking the users about their deadlines and scheduled for the work, so that you can pick a better time to roll out the new system and get them trained and comfortable in it before the critical deadlines. If the devs are resisting instead of the users, again check the time periods, if the deadlines are tight, and they know they will have a long ramp up to new methods, then now is not the moment.
You also want to talk to the resisters about the advantages of the new way to do things. And do not talk about them from your perspective but from theirs. A dev who is resisting might be more interested to learn the new methods are more attractive in a job market than the old methods. A reminder of some particular problems in the past and how hard they were to solve with the old method and how much easier with the new would also help. A user who is resisting might like to know that there will be fewer times when the system goes down or less bad data to fix later. They might like that it will be easier for them to answer their client's questions or resolve problems.
answered Nov 30 '15 at 20:10
HLGEM
133k25226489
I'm surprised you bothered to answer the question based on its unpolished and unclear state.
– AndreiROM
Nov 30 '15 at 20:40
This is pretty much exactly what I was going to say plus more words!
– blankip
Dec 1 '15 at 11:19
suggest improvements |Â
up vote
4
down vote
up vote
4
down vote
If you are having portions of the project removed because the users don't want to change how they have always done things, that is not a reflection on your technical abilities. It is commonplace and fairly normal.
It is not clear to me if the people who caused the reduction in scope are users who don't like having a new way to do things or devs who don't want to follow a new programming paradigm. So I will address both.
If you want to improve the possibility of getting new ideas into the software, you need to learn how to sell your ideas. First, it is hard to change people and how they have always done things, It is called resistance to change.
The way to get around the resistance is to find out what the new method will make easier for them, what new things they will be able to do that they couldn't and what current problems the current process has that you are fixing. For instance, if the current process frequently gets timeouts causing the data to not be saved, then people are going to be more easily persuaded to try something new.
But if the current method is working just fine, then why would they want to? In this case, you need to have something major to sell them on that will make the change worth it from their perspective. You must always keep their perspective in mind. Nobody who is not a developer cares if the code is more maintainable or uses a more modern programming language unless you can sell them on the idea of what they gain not what you gain from the change.
This is true even if the users you need to persuade are other developers. Maybe they are uncomfortable with the new methods because they don't understand them or they feel intimidated by something they haven't done before. Even devs need to be sold on using new tools especially in an environment like manufacturing where the devs aren't as willing to be on the cutting edge as say a startup.
All users are people first and have the need to feel comfortable with their work. Psychologically very few people embrace change.
So what you do first is find out from them what the problems with the current system are. It is important to ask the people who are resistant to change directly for their opinion on the current process and how they would improve it. More often than not, what others perceive as the problems are not at all what you might see. Understanding the problems they want solved in the new software will help you build a better solution. it will also give you something to sell your new idea with. Further you may find that the solution that looks good to you is actually more time-consuming and harder to use for them. If I have to process X number of widgets per hour, any process that makes me do more clicks and take longer is a problem even if the underlying software is easier to maintain. Remember, users typically spend their whole day using the software, things that look minor to you can really impact their daily productivity in a negative fashion.
Plus a good part of resistance to change is that they were not consulted on the change and had no input into it. The less input they have into a change, the more people will fight it. This is why it is 100% of the time a bad idea to get requirements only from managers (unless only managers use the system) which is an unfortunately common practice. You (or the Business analyst or whoever gathers the requirements) need to talk to users as well.
The next thing that concerns people is that they know how to do what they are doing now and they are afraid they will get thrown into the ocean with no life jacket with a new system.
You counter this fear by specifying how they are going to be trained on the new system and how the new system will be documented and what help in general they can expect during the learning phase. You also take care not to switch to a new method during critical time periods. You don't change the underlying timekeeping system right before payroll is due for instance. Again yo get this information by asking the users about their deadlines and scheduled for the work, so that you can pick a better time to roll out the new system and get them trained and comfortable in it before the critical deadlines. If the devs are resisting instead of the users, again check the time periods, if the deadlines are tight, and they know they will have a long ramp up to new methods, then now is not the moment.
You also want to talk to the resisters about the advantages of the new way to do things. And do not talk about them from your perspective but from theirs. A dev who is resisting might be more interested to learn the new methods are more attractive in a job market than the old methods. A reminder of some particular problems in the past and how hard they were to solve with the old method and how much easier with the new would also help. A user who is resisting might like to know that there will be fewer times when the system goes down or less bad data to fix later. They might like that it will be easier for them to answer their client's questions or resolve problems.
answered Nov 30 '15 at 20:10
HLGEM
133k25226489
If you are having portions of the project removed because the users don't want to change how they have always done things, that is not a reflection on your technical abilities. It is commonplace and fairly normal.
It is not clear to me if the people who caused the reduction in scope are users who don't like having a new way to do things or devs who don't want to follow a new programming paradigm. So I will address both.
If you want to improve the possibility of getting new ideas into the software, you need to learn how to sell your ideas. First, it is hard to change people and how they have always done things, It is called resistance to change.
The way to get around the resistance is to find out what the new method will make easier for them, what new things they will be able to do that they couldn't and what current problems the current process has that you are fixing. For instance, if the current process frequently gets timeouts causing the data to not be saved, then people are going to be more easily persuaded to try something new.
But if the current method is working just fine, then why would they want to? In this case, you need to have something major to sell them on that will make the change worth it from their perspective. You must always keep their perspective in mind. Nobody who is not a developer cares if the code is more maintainable or uses a more modern programming language unless you can sell them on the idea of what they gain not what you gain from the change.
This is true even if the users you need to persuade are other developers. Maybe they are uncomfortable with the new methods because they don't understand them or they feel intimidated by something they haven't done before. Even devs need to be sold on using new tools especially in an environment like manufacturing where the devs aren't as willing to be on the cutting edge as say a startup.
All users are people first and have the need to feel comfortable with their work. Psychologically very few people embrace change.
So what you do first is find out from them what the problems with the current system are. It is important to ask the people who are resistant to change directly for their opinion on the current process and how they would improve it. More often than not, what others perceive as the problems are not at all what you might see. Understanding the problems they want solved in the new software will help you build a better solution. it will also give you something to sell your new idea with. Further you may find that the solution that looks good to you is actually more time-consuming and harder to use for them. If I have to process X number of widgets per hour, any process that makes me do more clicks and take longer is a problem even if the underlying software is easier to maintain. Remember, users typically spend their whole day using the software, things that look minor to you can really impact their daily productivity in a negative fashion.
Plus a good part of resistance to change is that they were not consulted on the change and had no input into it. The less input they have into a change, the more people will fight it. This is why it is 100% of the time a bad idea to get requirements only from managers (unless only managers use the system) which is an unfortunately common practice. You (or the Business analyst or whoever gathers the requirements) need to talk to users as well.
The next thing that concerns people is that they know how to do what they are doing now and they are afraid they will get thrown into the ocean with no life jacket with a new system.
You counter this fear by specifying how they are going to be trained on the new system and how the new system will be documented and what help in general they can expect during the learning phase. You also take care not to switch to a new method during critical time periods. You don't change the underlying timekeeping system right before payroll is due for instance. Again yo get this information by asking the users about their deadlines and scheduled for the work, so that you can pick a better time to roll out the new system and get them trained and comfortable in it before the critical deadlines. If the devs are resisting instead of the users, again check the time periods, if the deadlines are tight, and they know they will have a long ramp up to new methods, then now is not the moment.
You also want to talk to the resisters about the advantages of the new way to do things. And do not talk about them from your perspective but from theirs. A dev who is resisting might be more interested to learn the new methods are more attractive in a job market than the old methods. A reminder of some particular problems in the past and how hard they were to solve with the old method and how much easier with the new would also help. A user who is resisting might like to know that there will be fewer times when the system goes down or less bad data to fix later. They might like that it will be easier for them to answer their client's questions or resolve problems.
answered Nov 30 '15 at 20:10
HLGEM
133k25226489
edited Nov 30 '15 at 20:30
answered Nov 30 '15 at 20:10
HLGEM
133k25226489
answered Nov 30 '15 at 20:10
HLGEM
133k25226489
answered Nov 30 '15 at 20:10
HLGEM
133k25226489
133k25226489
I'm surprised you bothered to answer the question based on its unpolished and unclear state.
– AndreiROM
Nov 30 '15 at 20:40
This is pretty much exactly what I was going to say plus more words!
– blankip
Dec 1 '15 at 11:19
suggest improvements |Â
I'm surprised you bothered to answer the question based on its unpolished and unclear state.
– AndreiROM
Nov 30 '15 at 20:40
This is pretty much exactly what I was going to say plus more words!
– blankip
Dec 1 '15 at 11:19
I'm surprised you bothered to answer the question based on its unpolished and unclear state.
– AndreiROM
Nov 30 '15 at 20:40
I'm surprised you bothered to answer the question based on its unpolished and unclear state.
– AndreiROM
Nov 30 '15 at 20:40
This is pretty much exactly what I was going to say plus more words!
– blankip
Dec 1 '15 at 11:19
This is pretty much exactly what I was going to say plus more words!
– blankip
Dec 1 '15 at 11:19
suggest improvements |Â
up vote
1
down vote
This suggests you should have been in touch with your prospective customer base earlier, to make sure everyone agreed on what was and wasn't important. That might have let you get them yo buy in on the new features; at worst you'd have known that any work on those features was for the next customer's benefit and would be ignored by these guys. (Gender not implied.)
They may discover the value of the new features later. Or, as I said, that may not happen until some time in the future.
Don't take it personally. You know you did a good job, your manager knows you did a good job, the customer knows you did a good job ... If the worst thing the other team can find to complain about is that you support features they don't expect to use, you did a great job!
edited Nov 30 '15 at 19:39
JB King
15.1k22957
answered Nov 30 '15 at 19:36
keshlam
41.5k1267144
suggest improvements |Â
up vote
1
down vote
This suggests you should have been in touch with your prospective customer base earlier, to make sure everyone agreed on what was and wasn't important. That might have let you get them yo buy in on the new features; at worst you'd have known that any work on those features was for the next customer's benefit and would be ignored by these guys. (Gender not implied.)
They may discover the value of the new features later. Or, as I said, that may not happen until some time in the future.
Don't take it personally. You know you did a good job, your manager knows you did a good job, the customer knows you did a good job ... If the worst thing the other team can find to complain about is that you support features they don't expect to use, you did a great job!
edited Nov 30 '15 at 19:39
JB King
15.1k22957
answered Nov 30 '15 at 19:36
keshlam
41.5k1267144
suggest improvements |Â
up vote
1
down vote
up vote
1
down vote
This suggests you should have been in touch with your prospective customer base earlier, to make sure everyone agreed on what was and wasn't important. That might have let you get them yo buy in on the new features; at worst you'd have known that any work on those features was for the next customer's benefit and would be ignored by these guys. (Gender not implied.)
They may discover the value of the new features later. Or, as I said, that may not happen until some time in the future.
Don't take it personally. You know you did a good job, your manager knows you did a good job, the customer knows you did a good job ... If the worst thing the other team can find to complain about is that you support features they don't expect to use, you did a great job!
edited Nov 30 '15 at 19:39
JB King
15.1k22957
answered Nov 30 '15 at 19:36
keshlam
41.5k1267144
This suggests you should have been in touch with your prospective customer base earlier, to make sure everyone agreed on what was and wasn't important. That might have let you get them yo buy in on the new features; at worst you'd have known that any work on those features was for the next customer's benefit and would be ignored by these guys. (Gender not implied.)
They may discover the value of the new features later. Or, as I said, that may not happen until some time in the future.
Don't take it personally. You know you did a good job, your manager knows you did a good job, the customer knows you did a good job ... If the worst thing the other team can find to complain about is that you support features they don't expect to use, you did a great job!
edited Nov 30 '15 at 19:39
JB King
15.1k22957
answered Nov 30 '15 at 19:36
keshlam
41.5k1267144
edited Nov 30 '15 at 19:39
JB King
15.1k22957
edited Nov 30 '15 at 19:39
JB King
15.1k22957
edited Nov 30 '15 at 19:39
JB King
15.1k22957
15.1k22957
answered Nov 30 '15 at 19:36
keshlam
41.5k1267144
answered Nov 30 '15 at 19:36
keshlam
41.5k1267144
answered Nov 30 '15 at 19:36
keshlam
41.5k1267144
41.5k1267144
suggest improvements |Â
suggest improvements |Â
up vote
1
down vote
That's the 30% rule. It's not always true, but after years, when you average, you're not far, I think...
30% of the code you write, you'll ditch yourself as irrelevant.
30% of the Ketp code won't ever be deployed, for some reason.
30% of the deployed code will never be used(product that didn't sell, people didn't go to that submenu, whatever).
30% of the used code is gonna be ditched within 2 years.
Etc.....
depending on your domain & firm, it can be more or less. But don't get sentimental with your code. Your heart is gonna be broken too often. Be proud of the small part that survives & thrives.
I did have personal code unused because noone ever subscribed the cats & dogs insurance, undeployed because a technical overhaul made it unusable(3 months of hard work), automated test scripts deployed but never ran because the manamgement module was never built, and many others like that. That's not a problem.
Other parts of my code are still running, and every year, when I'm receiving my bill for my car's insurance, I'm proud to say : "my own code did process this numbers. And It saved 1 full FTE of maintenance compared to the old systems".
Most of the rest disappeared, vanished, takes the dust, or is rarely used. I was payed for it. I didn't steal my pay. It now belongs to them. They do what they want with it.
answered Dec 1 '15 at 11:12
gazzz0x2z
5,93621634
indeed. And then there's the code you wrote but never got to deploy because the customer (or your own company) went bankrupt before it was finished (I've had both happen).
– jwenting
Dec 3 '15 at 6:54
suggest improvements |Â
up vote
1
down vote
That's the 30% rule. It's not always true, but after years, when you average, you're not far, I think...
30% of the code you write, you'll ditch yourself as irrelevant.
30% of the Ketp code won't ever be deployed, for some reason.
30% of the deployed code will never be used(product that didn't sell, people didn't go to that submenu, whatever).
30% of the used code is gonna be ditched within 2 years.
Etc.....
depending on your domain & firm, it can be more or less. But don't get sentimental with your code. Your heart is gonna be broken too often. Be proud of the small part that survives & thrives.
I did have personal code unused because noone ever subscribed the cats & dogs insurance, undeployed because a technical overhaul made it unusable(3 months of hard work), automated test scripts deployed but never ran because the manamgement module was never built, and many others like that. That's not a problem.
Other parts of my code are still running, and every year, when I'm receiving my bill for my car's insurance, I'm proud to say : "my own code did process this numbers. And It saved 1 full FTE of maintenance compared to the old systems".
Most of the rest disappeared, vanished, takes the dust, or is rarely used. I was payed for it. I didn't steal my pay. It now belongs to them. They do what they want with it.
answered Dec 1 '15 at 11:12
gazzz0x2z
5,93621634
indeed. And then there's the code you wrote but never got to deploy because the customer (or your own company) went bankrupt before it was finished (I've had both happen).
– jwenting
Dec 3 '15 at 6:54
suggest improvements |Â
up vote
1
down vote
up vote
1
down vote
That's the 30% rule. It's not always true, but after years, when you average, you're not far, I think...
30% of the code you write, you'll ditch yourself as irrelevant.
30% of the Ketp code won't ever be deployed, for some reason.
30% of the deployed code will never be used(product that didn't sell, people didn't go to that submenu, whatever).
30% of the used code is gonna be ditched within 2 years.
Etc.....
depending on your domain & firm, it can be more or less. But don't get sentimental with your code. Your heart is gonna be broken too often. Be proud of the small part that survives & thrives.
I did have personal code unused because noone ever subscribed the cats & dogs insurance, undeployed because a technical overhaul made it unusable(3 months of hard work), automated test scripts deployed but never ran because the manamgement module was never built, and many others like that. That's not a problem.
Other parts of my code are still running, and every year, when I'm receiving my bill for my car's insurance, I'm proud to say : "my own code did process this numbers. And It saved 1 full FTE of maintenance compared to the old systems".
Most of the rest disappeared, vanished, takes the dust, or is rarely used. I was payed for it. I didn't steal my pay. It now belongs to them. They do what they want with it.
answered Dec 1 '15 at 11:12
gazzz0x2z
5,93621634
That's the 30% rule. It's not always true, but after years, when you average, you're not far, I think...
30% of the code you write, you'll ditch yourself as irrelevant.
30% of the Ketp code won't ever be deployed, for some reason.
30% of the deployed code will never be used(product that didn't sell, people didn't go to that submenu, whatever).
30% of the used code is gonna be ditched within 2 years.
Etc.....
depending on your domain & firm, it can be more or less. But don't get sentimental with your code. Your heart is gonna be broken too often. Be proud of the small part that survives & thrives.
I did have personal code unused because noone ever subscribed the cats & dogs insurance, undeployed because a technical overhaul made it unusable(3 months of hard work), automated test scripts deployed but never ran because the manamgement module was never built, and many others like that. That's not a problem.
Other parts of my code are still running, and every year, when I'm receiving my bill for my car's insurance, I'm proud to say : "my own code did process this numbers. And It saved 1 full FTE of maintenance compared to the old systems".
Most of the rest disappeared, vanished, takes the dust, or is rarely used. I was payed for it. I didn't steal my pay. It now belongs to them. They do what they want with it.
answered Dec 1 '15 at 11:12
gazzz0x2z
5,93621634
answered Dec 1 '15 at 11:12
gazzz0x2z
5,93621634
answered Dec 1 '15 at 11:12
gazzz0x2z
5,93621634
answered Dec 1 '15 at 11:12
gazzz0x2z
5,93621634
5,93621634
indeed. And then there's the code you wrote but never got to deploy because the customer (or your own company) went bankrupt before it was finished (I've had both happen).
– jwenting
Dec 3 '15 at 6:54
suggest improvements |Â
indeed. And then there's the code you wrote but never got to deploy because the customer (or your own company) went bankrupt before it was finished (I've had both happen).
– jwenting
Dec 3 '15 at 6:54
indeed. And then there's the code you wrote but never got to deploy because the customer (or your own company) went bankrupt before it was finished (I've had both happen).
– jwenting
Dec 3 '15 at 6:54
indeed. And then there's the code you wrote but never got to deploy because the customer (or your own company) went bankrupt before it was finished (I've had both happen).
– jwenting
Dec 3 '15 at 6:54
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%2f58541%2fwork-being-cut-out%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
Is this the company you have worked for for 15 years saying "this is not the way we have always done things", or a customer?
– DJClayworth
Nov 30 '15 at 20:31
1
Hi Lauren. As your question stands, it's asking for people's opinions, which is going to get it closed. I would suggest providing more details: Is this an internal project which you're developing for in-house users, or for external ones? Who's giving you the "it's not the way we do things" feedback? Does this project represent a paradigm shift of dev techniques or tech for the company? Did you develop the project in isolation, or based on specs determined by speaking with the intended users and management? All of these are vital to us understanding the context of your question.
– AndreiROM
Nov 30 '15 at 20:37
"this isn't the way we have always done it." - another name for this is "company standards" or "company practices". However, as JoeStrazzere points out this is different from removing a requirement. If your users had an undo feature before, and now you've removed it, I personally can't imagine they would accept that. I remember using software before "undo" was the general expectation. But now that it's the norm, it's hard to go back. Nonetheless, if your manager decides it's not needed, that's probably on him.
– Brandin
Dec 1 '15 at 11:35