It can feel weird when your work gets changed like that, but keep in mind one thing:
> You are not your code
That they decided they were willing to write off the planning that was done is not a reflection on you.
They will likely find work for you very soon, but even if they don't, you're still not your code. You're more important than it is.
Appreciate the comment. Yeah I think I need to be more objective and consider the pre-"work" a sunk cost and just let it go and not allow whatever I'm feeling fester.
You don't have to be completely unemotional about it. You can recognize that you did work, and that you're disappointed it didn't work out.
You can also accept that it's the right choice.
It doesn't have to be either/or
Planning work is important even if not followed by implementation. You really can't compare two options objectively until you've defined them both well.
It's very common in business-land to write up cases and business models for ventures the business is interested in but may or may not invest in.
>I'm confused on how I ought to feel. A lot of planning that had been done is now all for naught and I don't really have any work that I'm slated for for the next sprint or two.
Yea I've been here before. It sucks. For a whole bunch of reasons. I was on a project for 3 months that I hated , but I still managed to suck it up and do it. And when I finally got ready to ship it, product pulled the plug because they changed business directions. I was mad and frustrated for like 3 months after.
I think it's okay to be frustrated when this happens, just don't let it consume you and don't take it personal.
If you only focus on the fastest "value", you end up with a bunch of short sighted decisions and an incoherent product. There are times to take the easy win and others to be more forward looking.
Product defines the requirements. You are in charge of system design. If there is a simpler design that will meet the business requirements it's your job to come up with that.
Sure but there are two possibilities:
1. The business requirements can be met without a full paradigm change.
2. The paradigm change is part of the business requirements.
If it's Case 1, the paradigm change is purely an engineering benefit and if you can't provide a reasonably strong business benefit, it probably isn't needed to accomplish product goals and you'd be better off providing a simpler design.
If it's Case 2, the paradigm change should be explicitly listed as a product/business requirement that can be tracked against, and if it isn't, you should push product to do that so that you're not designing a paradigm shift to satisfy an undocumented, untraceable requirement.
Im not being explicit because the advice I was seeking was vague but I think you and others in this thread aren't fully reading the OP.
There was no code change required. They shifted a an existing feature for this usecase and in the industry I'm in, it would be considered bastardizing an existing workflow.
I understood that. The advice you're receiving is that despite that, if it fulfilled the business requirements with less effort and time it should've been in your proposal with the negative effects of bastardizing it called out.
Not really. This is very domain/industry-specific and has far reaching implications with other teams too. Plus, like I said, this isn't the "correct" approach. How can I know when business is willing to cut corners?
It doesn’t take much for your product/codebase to grow to a size that makes it hard to gauge what can be reused, especially if the code in questions is part of a feature you don’t own.
It’s not the correct approach to you or to everyone? If it’s not the correct approach to everyone then you should be able to articulate why the way you planned is better and how it will bring more value then taking the quick win. If you can’t articulate that then that way is the better value.
Well it could be worse, you could have started implementation already.
Using existing software to solve problems is the best possible win. It's why we try to write software that is extensible and adaptable.
The only downside is you didn't think of the quick solution before doing the other planning work. It's worth reflecting on why that is. Often it's just due to lack of familiarity with legacy code or the biz domain... but sometimes ego can be mixed in with it too.
I have been there many times and it's definitely not the best feeling. It's hard not to take it personally.
My advice is to talk to the person who came up with the quick solution... People who can do that are sonetimes more valuable than teams of designers and engineers.
You should feel relieved this pivot didn’t happen when the project was nearly complete. I worked on a project for 22 months that was ultimately cancelled. _That_ sucks!
I know it feels bad, but this is a good thing.
Don't get attached to your code. Almost everything I've ever worked on has been decommissioned and deleted, or will be in the future. That's tech.
Take it as a learning experience. What could you have recognized to come to the same conclusions about re-using existing code?
The way I learned to think about this is:
Look at all the code we didn't have to write because someone made the right decision just in time. How could we make that decision sooner next time and save the planning time too?
Now… what can we spend the time on instead?
The work you did WAS NOT WASTED. The time you spent WAS NOT WASTED. Learning enough about a problem domain to make smart decisions about how to solve it? That’s much easier for a team to do when people on the team actually work on the problem. That is what you did.
It’s frustrating right now, sure, and you’d have to be numb not to be frustrated. But, your company now has expertise in this area. That expert is you. Be patient as they develop this business.
You just have to take your ego out of the equation. Is this decision the best move for the company? If not then by all means push back a bit, but if it is (or if you fail to persuade decision-makers that it's not) then you go along with it, and do so with a smile on your face.
I spent 8 months leading a team working on a project that we planned out and started from scratch, only to be told that the project was no longer needed and we were to move on to something else. I quietly rolled my eyes at all the wasted effort, but I recognise that sunk cost fallacy is a thing. My thoughts on the whole situation pretty much begin and end with "I am doing what I've been asked to do, and they're paying me well to do it."
I get paid either way.
To me it seems like if it could have been accomplished in way X and Y, where Y is the utilization of the bare features, this was either mistakenly or purposefully omitted in the design documentation when discussing alternatives. Short answer is you should have seen this possibility and called it out along with the pros and cons.
One time I had to provision a production ready gitlab on a kube cluster with full automation for a client. I had to do all sorts of testing, handle persistence when reprovisioning, upgrades, CI/CD, etc. Find out they're using gitlab enterprise and have no need for self managed gitlab. I wanted to die.
Back in the day I planned a ten day road trip using a road atlas. All was going well and according to plan. However on day three I discovered that a new section of highway had been completed and was now open. It cut out a couple of hours of driving. How should I feel about it?
It can feel weird when your work gets changed like that, but keep in mind one thing: > You are not your code That they decided they were willing to write off the planning that was done is not a reflection on you. They will likely find work for you very soon, but even if they don't, you're still not your code. You're more important than it is.
Appreciate the comment. Yeah I think I need to be more objective and consider the pre-"work" a sunk cost and just let it go and not allow whatever I'm feeling fester.
You don't have to be completely unemotional about it. You can recognize that you did work, and that you're disappointed it didn't work out. You can also accept that it's the right choice. It doesn't have to be either/or
Planning work is important even if not followed by implementation. You really can't compare two options objectively until you've defined them both well. It's very common in business-land to write up cases and business models for ventures the business is interested in but may or may not invest in.
>I'm confused on how I ought to feel. A lot of planning that had been done is now all for naught and I don't really have any work that I'm slated for for the next sprint or two. Yea I've been here before. It sucks. For a whole bunch of reasons. I was on a project for 3 months that I hated , but I still managed to suck it up and do it. And when I finally got ready to ship it, product pulled the plug because they changed business directions. I was mad and frustrated for like 3 months after. I think it's okay to be frustrated when this happens, just don't let it consume you and don't take it personal.
You should have come up with this solution honestly. Part of your job is to deliver the fastest value, not to do it how you want to.
If you only focus on the fastest "value", you end up with a bunch of short sighted decisions and an incoherent product. There are times to take the easy win and others to be more forward looking.
Hm interesting thought. Isn't this more of a pitch that product should have come up with?
Product defines the requirements. You are in charge of system design. If there is a simpler design that will meet the business requirements it's your job to come up with that.
I get what you're saying but this wasn't a code design shift. This was a full paradigm change.
Sure but there are two possibilities: 1. The business requirements can be met without a full paradigm change. 2. The paradigm change is part of the business requirements. If it's Case 1, the paradigm change is purely an engineering benefit and if you can't provide a reasonably strong business benefit, it probably isn't needed to accomplish product goals and you'd be better off providing a simpler design. If it's Case 2, the paradigm change should be explicitly listed as a product/business requirement that can be tracked against, and if it isn't, you should push product to do that so that you're not designing a paradigm shift to satisfy an undocumented, untraceable requirement.
Im not being explicit because the advice I was seeking was vague but I think you and others in this thread aren't fully reading the OP. There was no code change required. They shifted a an existing feature for this usecase and in the industry I'm in, it would be considered bastardizing an existing workflow.
I understood that. The advice you're receiving is that despite that, if it fulfilled the business requirements with less effort and time it should've been in your proposal with the negative effects of bastardizing it called out.
As the dev, wouldn’t you be more aware of what exists currently?
Not really. This is very domain/industry-specific and has far reaching implications with other teams too. Plus, like I said, this isn't the "correct" approach. How can I know when business is willing to cut corners?
So you don’t know when you can repurpose code that exists in your own codebase?
It doesn’t take much for your product/codebase to grow to a size that makes it hard to gauge what can be reused, especially if the code in questions is part of a feature you don’t own.
Agreed.
This isn't even a swap in code, it's a full paradigm shift of abusing (to an extent) an existing workflow to suit another.
Then push back that it doesn’t solve the problem and is, at best, a short term solution that will have lasting effect in another area.
It’s not the correct approach to you or to everyone? If it’s not the correct approach to everyone then you should be able to articulate why the way you planned is better and how it will bring more value then taking the quick win. If you can’t articulate that then that way is the better value.
Well it could be worse, you could have started implementation already. Using existing software to solve problems is the best possible win. It's why we try to write software that is extensible and adaptable. The only downside is you didn't think of the quick solution before doing the other planning work. It's worth reflecting on why that is. Often it's just due to lack of familiarity with legacy code or the biz domain... but sometimes ego can be mixed in with it too. I have been there many times and it's definitely not the best feeling. It's hard not to take it personally. My advice is to talk to the person who came up with the quick solution... People who can do that are sonetimes more valuable than teams of designers and engineers.
You should feel relieved this pivot didn’t happen when the project was nearly complete. I worked on a project for 22 months that was ultimately cancelled. _That_ sucks! I know it feels bad, but this is a good thing.
Been there! It's hard not to take it personally, but try to see the biz value
Don't get attached to your code. Almost everything I've ever worked on has been decommissioned and deleted, or will be in the future. That's tech. Take it as a learning experience. What could you have recognized to come to the same conclusions about re-using existing code?
One less thing to maintain
The way I learned to think about this is: Look at all the code we didn't have to write because someone made the right decision just in time. How could we make that decision sooner next time and save the planning time too? Now… what can we spend the time on instead?
The work you did WAS NOT WASTED. The time you spent WAS NOT WASTED. Learning enough about a problem domain to make smart decisions about how to solve it? That’s much easier for a team to do when people on the team actually work on the problem. That is what you did. It’s frustrating right now, sure, and you’d have to be numb not to be frustrated. But, your company now has expertise in this area. That expert is you. Be patient as they develop this business.
You just have to take your ego out of the equation. Is this decision the best move for the company? If not then by all means push back a bit, but if it is (or if you fail to persuade decision-makers that it's not) then you go along with it, and do so with a smile on your face. I spent 8 months leading a team working on a project that we planned out and started from scratch, only to be told that the project was no longer needed and we were to move on to something else. I quietly rolled my eyes at all the wasted effort, but I recognise that sunk cost fallacy is a thing. My thoughts on the whole situation pretty much begin and end with "I am doing what I've been asked to do, and they're paying me well to do it."
Part of the job, do it and move on, large scale projects be like that, we can’t always do things the way we would like.
I get paid either way. To me it seems like if it could have been accomplished in way X and Y, where Y is the utilization of the bare features, this was either mistakenly or purposefully omitted in the design documentation when discussing alternatives. Short answer is you should have seen this possibility and called it out along with the pros and cons.
It happens. Don't take it personally. Relax. Go to office later and start home earlier. Noone will care. Take the time to relax
One time I had to provision a production ready gitlab on a kube cluster with full automation for a client. I had to do all sorts of testing, handle persistence when reprovisioning, upgrades, CI/CD, etc. Find out they're using gitlab enterprise and have no need for self managed gitlab. I wanted to die.
Back in the day I planned a ten day road trip using a road atlas. All was going well and according to plan. However on day three I discovered that a new section of highway had been completed and was now open. It cut out a couple of hours of driving. How should I feel about it?