Mixing
Dealing with unrealistic deadlines [duplicate]
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
5
down vote
favorite
This question already has an answer here:
How can we protest a deadline that is too short?
9 answers
I'm seeking advice on how to deal with unrealistic deadlines at work. The issue is that the company I'm working for is making a huge pivot, however there is an expectation that the pivot will occur quite rapidly and that the previous technology solutions will be sufficient to make this a smooth transition.
To the contrary, I have discovered recently that the real amount of time to implement the new product is going to take a few more months than planned, mostly because new technology will have to be used, and a large amount of refactors are required. So far, the management team hasn't been quite receptive to this news, and are hoping I actually drop the much needed refactors.
I'm looking for advice on how to handle these kind of unrealistic expectations and how to move forward. I really like the company, but I think that there is a lot of stress here since the company is losing a lot of users daily.
management project-management
edited Jul 21 '15 at 10:23
mhoran_psprep
40.3k462144
asked Jul 21 '15 at 5:21
TheM00s3
512211
marked as duplicate by gnat, Snow♦, Draken, scaaahu, Mister Positive Oct 11 '17 at 11:30
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
 |Â
show 2 more comments
up vote
5
down vote
favorite
This question already has an answer here:
How can we protest a deadline that is too short?
9 answers
I'm seeking advice on how to deal with unrealistic deadlines at work. The issue is that the company I'm working for is making a huge pivot, however there is an expectation that the pivot will occur quite rapidly and that the previous technology solutions will be sufficient to make this a smooth transition.
To the contrary, I have discovered recently that the real amount of time to implement the new product is going to take a few more months than planned, mostly because new technology will have to be used, and a large amount of refactors are required. So far, the management team hasn't been quite receptive to this news, and are hoping I actually drop the much needed refactors.
I'm looking for advice on how to handle these kind of unrealistic expectations and how to move forward. I really like the company, but I think that there is a lot of stress here since the company is losing a lot of users daily.
management project-management
edited Jul 21 '15 at 10:23
mhoran_psprep
40.3k462144
asked Jul 21 '15 at 5:21
TheM00s3
512211
marked as duplicate by gnat, Snow♦, Draken, scaaahu, Mister Positive Oct 11 '17 at 11:30
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
3
welcome to the world of programming. This happens to most of us. The only possible way to handle this situation is by increasing your strengths, having a good history of previous "realistic" dead lines and clearly communicating how much you will be able to do in given time.
– Amit
Jul 21 '15 at 5:39
The other answer is to figure out how much can be deferred until after the deadline. Do a quich-and-dirty adapti9n now, then come back and do the clean refactorings later. This is software engineering, not computer science; "on time and under budget" sometimes legitimately trumps "but it'll cost us less in the long run if...". Quoting Steve Bois: " Make it work. Make it good. Make it great." In that order.
– keshlam
Jul 21 '15 at 6:02
4
@keshlam: although the real world almost invariably stops at "Make it work" :)
– Juha Untinen
Jul 21 '15 at 6:58
1
Refactoring is done to make your code easier to maintain in future. Clearly the present is much higher priority then the future in your company, so yes you should drop the refactoring. You need to communicate a better reason to your managers why the deadlines won't be met
– cowls
Jul 21 '15 at 7:29
3
Refactoring may be needed right now, because it may be just impossible to make the old code work with the new features. If the existing code is bad enough, refactoring can be cheaper in the short run.
– gnasher729
Jul 21 '15 at 10:40
 |Â
show 2 more comments
up vote
5
down vote
favorite
up vote
5
down vote
favorite
This question already has an answer here:
How can we protest a deadline that is too short?
9 answers
I'm seeking advice on how to deal with unrealistic deadlines at work. The issue is that the company I'm working for is making a huge pivot, however there is an expectation that the pivot will occur quite rapidly and that the previous technology solutions will be sufficient to make this a smooth transition.
To the contrary, I have discovered recently that the real amount of time to implement the new product is going to take a few more months than planned, mostly because new technology will have to be used, and a large amount of refactors are required. So far, the management team hasn't been quite receptive to this news, and are hoping I actually drop the much needed refactors.
I'm looking for advice on how to handle these kind of unrealistic expectations and how to move forward. I really like the company, but I think that there is a lot of stress here since the company is losing a lot of users daily.
management project-management
edited Jul 21 '15 at 10:23
mhoran_psprep
40.3k462144
asked Jul 21 '15 at 5:21
TheM00s3
512211
This question already has an answer here:
How can we protest a deadline that is too short?
9 answers
I'm seeking advice on how to deal with unrealistic deadlines at work. The issue is that the company I'm working for is making a huge pivot, however there is an expectation that the pivot will occur quite rapidly and that the previous technology solutions will be sufficient to make this a smooth transition.
To the contrary, I have discovered recently that the real amount of time to implement the new product is going to take a few more months than planned, mostly because new technology will have to be used, and a large amount of refactors are required. So far, the management team hasn't been quite receptive to this news, and are hoping I actually drop the much needed refactors.
I'm looking for advice on how to handle these kind of unrealistic expectations and how to move forward. I really like the company, but I think that there is a lot of stress here since the company is losing a lot of users daily.
This question already has an answer here:
How can we protest a deadline that is too short?
9 answers
management project-management
edited Jul 21 '15 at 10:23
mhoran_psprep
40.3k462144
asked Jul 21 '15 at 5:21
TheM00s3
512211
edited Jul 21 '15 at 10:23
mhoran_psprep
40.3k462144
edited Jul 21 '15 at 10:23
mhoran_psprep
40.3k462144
edited Jul 21 '15 at 10:23
mhoran_psprep
40.3k462144
40.3k462144
asked Jul 21 '15 at 5:21
TheM00s3
512211
asked Jul 21 '15 at 5:21
TheM00s3
512211
asked Jul 21 '15 at 5:21
TheM00s3
512211
512211
marked as duplicate by gnat, Snow♦, Draken, scaaahu, Mister Positive Oct 11 '17 at 11:30
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
marked as duplicate by gnat, Snow♦, Draken, scaaahu, Mister Positive Oct 11 '17 at 11:30
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
3
welcome to the world of programming. This happens to most of us. The only possible way to handle this situation is by increasing your strengths, having a good history of previous "realistic" dead lines and clearly communicating how much you will be able to do in given time.
– Amit
Jul 21 '15 at 5:39
The other answer is to figure out how much can be deferred until after the deadline. Do a quich-and-dirty adapti9n now, then come back and do the clean refactorings later. This is software engineering, not computer science; "on time and under budget" sometimes legitimately trumps "but it'll cost us less in the long run if...". Quoting Steve Bois: " Make it work. Make it good. Make it great." In that order.
– keshlam
Jul 21 '15 at 6:02
4
@keshlam: although the real world almost invariably stops at "Make it work" :)
– Juha Untinen
Jul 21 '15 at 6:58
1
Refactoring is done to make your code easier to maintain in future. Clearly the present is much higher priority then the future in your company, so yes you should drop the refactoring. You need to communicate a better reason to your managers why the deadlines won't be met
– cowls
Jul 21 '15 at 7:29
3
Refactoring may be needed right now, because it may be just impossible to make the old code work with the new features. If the existing code is bad enough, refactoring can be cheaper in the short run.
– gnasher729
Jul 21 '15 at 10:40
 |Â
show 2 more comments
3
welcome to the world of programming. This happens to most of us. The only possible way to handle this situation is by increasing your strengths, having a good history of previous "realistic" dead lines and clearly communicating how much you will be able to do in given time.
– Amit
Jul 21 '15 at 5:39
The other answer is to figure out how much can be deferred until after the deadline. Do a quich-and-dirty adapti9n now, then come back and do the clean refactorings later. This is software engineering, not computer science; "on time and under budget" sometimes legitimately trumps "but it'll cost us less in the long run if...". Quoting Steve Bois: " Make it work. Make it good. Make it great." In that order.
– keshlam
Jul 21 '15 at 6:02
4
@keshlam: although the real world almost invariably stops at "Make it work" :)
– Juha Untinen
Jul 21 '15 at 6:58
1
Refactoring is done to make your code easier to maintain in future. Clearly the present is much higher priority then the future in your company, so yes you should drop the refactoring. You need to communicate a better reason to your managers why the deadlines won't be met
– cowls
Jul 21 '15 at 7:29
3
Refactoring may be needed right now, because it may be just impossible to make the old code work with the new features. If the existing code is bad enough, refactoring can be cheaper in the short run.
– gnasher729
Jul 21 '15 at 10:40
3
3
welcome to the world of programming. This happens to most of us. The only possible way to handle this situation is by increasing your strengths, having a good history of previous "realistic" dead lines and clearly communicating how much you will be able to do in given time.
– Amit
Jul 21 '15 at 5:39
welcome to the world of programming. This happens to most of us. The only possible way to handle this situation is by increasing your strengths, having a good history of previous "realistic" dead lines and clearly communicating how much you will be able to do in given time.
– Amit
Jul 21 '15 at 5:39
The other answer is to figure out how much can be deferred until after the deadline. Do a quich-and-dirty adapti9n now, then come back and do the clean refactorings later. This is software engineering, not computer science; "on time and under budget" sometimes legitimately trumps "but it'll cost us less in the long run if...". Quoting Steve Bois: " Make it work. Make it good. Make it great." In that order.
– keshlam
Jul 21 '15 at 6:02
The other answer is to figure out how much can be deferred until after the deadline. Do a quich-and-dirty adapti9n now, then come back and do the clean refactorings later. This is software engineering, not computer science; "on time and under budget" sometimes legitimately trumps "but it'll cost us less in the long run if...". Quoting Steve Bois: " Make it work. Make it good. Make it great." In that order.
– keshlam
Jul 21 '15 at 6:02
4
4
@keshlam: although the real world almost invariably stops at "Make it work" :)
– Juha Untinen
Jul 21 '15 at 6:58
@keshlam: although the real world almost invariably stops at "Make it work" :)
– Juha Untinen
Jul 21 '15 at 6:58
1
1
Refactoring is done to make your code easier to maintain in future. Clearly the present is much higher priority then the future in your company, so yes you should drop the refactoring. You need to communicate a better reason to your managers why the deadlines won't be met
– cowls
Jul 21 '15 at 7:29
Refactoring is done to make your code easier to maintain in future. Clearly the present is much higher priority then the future in your company, so yes you should drop the refactoring. You need to communicate a better reason to your managers why the deadlines won't be met
– cowls
Jul 21 '15 at 7:29
3
3
Refactoring may be needed right now, because it may be just impossible to make the old code work with the new features. If the existing code is bad enough, refactoring can be cheaper in the short run.
– gnasher729
Jul 21 '15 at 10:40
Refactoring may be needed right now, because it may be just impossible to make the old code work with the new features. If the existing code is bad enough, refactoring can be cheaper in the short run.
– gnasher729
Jul 21 '15 at 10:40
 |Â
show 2 more comments
4 Answers
4
active
oldest
votes
up vote
13
down vote
accepted
If there is an unrealistic deadline, one of the following has to happen:
- a. Extend the deadline / b. deliver past the deadline.
- Drop features.
- Drop quality (expect the odd crash or data loss here and there).
- Bring in someone highly qualified who can contribute significantly to the work, that is expensive.
- Work ridiculous hours and make yourself ill as the result, with dubious results.
What doesn't work, but what your management seems to do, is
- Close your eyes and ears to anyone who tells you the deadline is at risk.
Number 5 has the disadvantage of making you ill, without any advantages for you (company isn't going to pay overtime, or going to thank you, but realise that you can be taken advantage of), and it doesn't help much anyway, so that is the option that you must avoid and refuse at any cost.
I'd suggest to create a list of features that could be dropped while still having a useful product, and a list of points where quality can be dropped, including the obvious consequences. Your management then needs to decide what to do. If necessary make them aware that option 6 doesn't work (tread carefully there), and that option 1b. will happen automatically.
What you need to emphasize is that without action, the deadline will not be met.
answered Jul 21 '15 at 6:15
gnasher729
71k31131222
Only bumped into this recently, but this is an excellent summary with some corporate life rules that I take wherever I go.
– Maarten
Nov 3 '17 at 9:36
suggest improvements |Â
up vote
5
down vote
Firstly - accept that if this really is the case, it's not okay. Too many programmers take home work with them and stay silent on these issues leaving management in the dark (even if they appear to not be).
You also never want to present a problem without some sort of reasoning or a solution. To do this - communication is key. Not just telling your manager that you're not going to be able to reach a deadline but refining how you communicate it.
If I were in your position I would break down the work into items and put timing, and deadlines around each of them. You can then use this to communicate exactly why the deadline isn't achievable, with hard data that the business can feel comfortable making a decision upon. If you're comfortable doing so (depending on your level and the team) you could even suggest some compromises that could be made (with changes or your own schedule) to help get the project back on track.
Should this not work I often continue to update a worksheet as the project commences sending a weekly (or if necessary daily) summary of the work items that have been completed, any blockers to getting work done and the forecasted schedule.
answered Jul 21 '15 at 6:14
Codingo
3,24331941
suggest improvements |Â
up vote
2
down vote
First of all, it sounds like your company is abusing concept of deadlines and estimations - estimations are estimations and that is all they are. Nobody, ever should expect for a estimation to fit in a deadline exactly and deadline should have a very reasonable safety buffer over estimation for exactly these situations. Delivering sooner is okay, delivering past the deadline is not.
Amending to the previous answers, and based on my previous experience this might as well be a communication issue for one simple reason - people in management often lack technical skills and understanding, and simply put, they are underestimating the importance of software quality which is a real need in this case apparently, as you stated that a lot of refactoring will be needed. Based on that, you should probably present management with the fact that doing it later will cost more, as technical debt only increases and the problem that already exists will not simply go away if postponed - it will increase in severity as you add more and more complexity to the project, and that increase will be exponential to the point where maintaining the project will suck up huge amount of resources. I don't think a wise management will pass on this if it is absolutely certain they will loose money if this continues in a way that it does.
If this is a inside product, argument that we should actually produce something that works well instead of a half baked cake should pass with flying colors.
If this is a product for some external customer, even more - people usually are reasonable enough to accept extending deadlines if that means the end result will improve by order of magnitude.
Last, but not least, you should figure out why this gross underestimation happened in the first place and place a mechanism from preventing it from happening in the future - were the tech people not involved in estimations? Was something important excluded from the estimations, and if so, why? And if so, why was not the deadline extended after it was proven to be unrealistic?
answered Jul 21 '15 at 21:34
Matiss
369310
suggest improvements |Â
up vote
1
down vote
Sorry, but I think you're approaching the problem from too much of an engineering standpoint. It's easy to just accuse management of not being reasonable especially if they're not technically savvy, but you are losing clients. That is a reality.
Like all emergency situations (severe loss and damage with little time and resources), you have to triage. In your case, it has to happen on both the Refactoring and the Feature/Requirements areas. Get those two in synch if possible. If feature A will help retain the most clients, refactor that part of the code base if necessary. At least limit the refactoring in areas with the least interest to your clients. I realize you may be refactoring generalized areas, utilities or frameworks.
I'm skeptical about this large makeover at a time when clients are not satisfied with your application. Fix what you have to solve their problems. If you can get me across the river, I don't need a new bridge.
suggest improvements |Â
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
13
down vote
accepted
If there is an unrealistic deadline, one of the following has to happen:
- a. Extend the deadline / b. deliver past the deadline.
- Drop features.
- Drop quality (expect the odd crash or data loss here and there).
- Bring in someone highly qualified who can contribute significantly to the work, that is expensive.
- Work ridiculous hours and make yourself ill as the result, with dubious results.
What doesn't work, but what your management seems to do, is
- Close your eyes and ears to anyone who tells you the deadline is at risk.
Number 5 has the disadvantage of making you ill, without any advantages for you (company isn't going to pay overtime, or going to thank you, but realise that you can be taken advantage of), and it doesn't help much anyway, so that is the option that you must avoid and refuse at any cost.
I'd suggest to create a list of features that could be dropped while still having a useful product, and a list of points where quality can be dropped, including the obvious consequences. Your management then needs to decide what to do. If necessary make them aware that option 6 doesn't work (tread carefully there), and that option 1b. will happen automatically.
What you need to emphasize is that without action, the deadline will not be met.
answered Jul 21 '15 at 6:15
gnasher729
71k31131222
Only bumped into this recently, but this is an excellent summary with some corporate life rules that I take wherever I go.
– Maarten
Nov 3 '17 at 9:36
suggest improvements |Â
up vote
13
down vote
accepted
If there is an unrealistic deadline, one of the following has to happen:
- a. Extend the deadline / b. deliver past the deadline.
- Drop features.
- Drop quality (expect the odd crash or data loss here and there).
- Bring in someone highly qualified who can contribute significantly to the work, that is expensive.
- Work ridiculous hours and make yourself ill as the result, with dubious results.
What doesn't work, but what your management seems to do, is
- Close your eyes and ears to anyone who tells you the deadline is at risk.
Number 5 has the disadvantage of making you ill, without any advantages for you (company isn't going to pay overtime, or going to thank you, but realise that you can be taken advantage of), and it doesn't help much anyway, so that is the option that you must avoid and refuse at any cost.
I'd suggest to create a list of features that could be dropped while still having a useful product, and a list of points where quality can be dropped, including the obvious consequences. Your management then needs to decide what to do. If necessary make them aware that option 6 doesn't work (tread carefully there), and that option 1b. will happen automatically.
What you need to emphasize is that without action, the deadline will not be met.
answered Jul 21 '15 at 6:15
gnasher729
71k31131222
Only bumped into this recently, but this is an excellent summary with some corporate life rules that I take wherever I go.
– Maarten
Nov 3 '17 at 9:36
suggest improvements |Â
up vote
13
down vote
accepted
up vote
13
down vote
accepted
If there is an unrealistic deadline, one of the following has to happen:
- a. Extend the deadline / b. deliver past the deadline.
- Drop features.
- Drop quality (expect the odd crash or data loss here and there).
- Bring in someone highly qualified who can contribute significantly to the work, that is expensive.
- Work ridiculous hours and make yourself ill as the result, with dubious results.
What doesn't work, but what your management seems to do, is
- Close your eyes and ears to anyone who tells you the deadline is at risk.
Number 5 has the disadvantage of making you ill, without any advantages for you (company isn't going to pay overtime, or going to thank you, but realise that you can be taken advantage of), and it doesn't help much anyway, so that is the option that you must avoid and refuse at any cost.
I'd suggest to create a list of features that could be dropped while still having a useful product, and a list of points where quality can be dropped, including the obvious consequences. Your management then needs to decide what to do. If necessary make them aware that option 6 doesn't work (tread carefully there), and that option 1b. will happen automatically.
What you need to emphasize is that without action, the deadline will not be met.
answered Jul 21 '15 at 6:15
gnasher729
71k31131222
If there is an unrealistic deadline, one of the following has to happen:
- a. Extend the deadline / b. deliver past the deadline.
- Drop features.
- Drop quality (expect the odd crash or data loss here and there).
- Bring in someone highly qualified who can contribute significantly to the work, that is expensive.
- Work ridiculous hours and make yourself ill as the result, with dubious results.
What doesn't work, but what your management seems to do, is
- Close your eyes and ears to anyone who tells you the deadline is at risk.
Number 5 has the disadvantage of making you ill, without any advantages for you (company isn't going to pay overtime, or going to thank you, but realise that you can be taken advantage of), and it doesn't help much anyway, so that is the option that you must avoid and refuse at any cost.
I'd suggest to create a list of features that could be dropped while still having a useful product, and a list of points where quality can be dropped, including the obvious consequences. Your management then needs to decide what to do. If necessary make them aware that option 6 doesn't work (tread carefully there), and that option 1b. will happen automatically.
What you need to emphasize is that without action, the deadline will not be met.
answered Jul 21 '15 at 6:15
gnasher729
71k31131222
answered Jul 21 '15 at 6:15
gnasher729
71k31131222
answered Jul 21 '15 at 6:15
gnasher729
71k31131222
answered Jul 21 '15 at 6:15
gnasher729
71k31131222
71k31131222
Only bumped into this recently, but this is an excellent summary with some corporate life rules that I take wherever I go.
– Maarten
Nov 3 '17 at 9:36
suggest improvements |Â
Only bumped into this recently, but this is an excellent summary with some corporate life rules that I take wherever I go.
– Maarten
Nov 3 '17 at 9:36
Only bumped into this recently, but this is an excellent summary with some corporate life rules that I take wherever I go.
– Maarten
Nov 3 '17 at 9:36
Only bumped into this recently, but this is an excellent summary with some corporate life rules that I take wherever I go.
– Maarten
Nov 3 '17 at 9:36
suggest improvements |Â
up vote
5
down vote
Firstly - accept that if this really is the case, it's not okay. Too many programmers take home work with them and stay silent on these issues leaving management in the dark (even if they appear to not be).
You also never want to present a problem without some sort of reasoning or a solution. To do this - communication is key. Not just telling your manager that you're not going to be able to reach a deadline but refining how you communicate it.
If I were in your position I would break down the work into items and put timing, and deadlines around each of them. You can then use this to communicate exactly why the deadline isn't achievable, with hard data that the business can feel comfortable making a decision upon. If you're comfortable doing so (depending on your level and the team) you could even suggest some compromises that could be made (with changes or your own schedule) to help get the project back on track.
Should this not work I often continue to update a worksheet as the project commences sending a weekly (or if necessary daily) summary of the work items that have been completed, any blockers to getting work done and the forecasted schedule.
answered Jul 21 '15 at 6:14
Codingo
3,24331941
suggest improvements |Â
up vote
5
down vote
Firstly - accept that if this really is the case, it's not okay. Too many programmers take home work with them and stay silent on these issues leaving management in the dark (even if they appear to not be).
You also never want to present a problem without some sort of reasoning or a solution. To do this - communication is key. Not just telling your manager that you're not going to be able to reach a deadline but refining how you communicate it.
If I were in your position I would break down the work into items and put timing, and deadlines around each of them. You can then use this to communicate exactly why the deadline isn't achievable, with hard data that the business can feel comfortable making a decision upon. If you're comfortable doing so (depending on your level and the team) you could even suggest some compromises that could be made (with changes or your own schedule) to help get the project back on track.
Should this not work I often continue to update a worksheet as the project commences sending a weekly (or if necessary daily) summary of the work items that have been completed, any blockers to getting work done and the forecasted schedule.
answered Jul 21 '15 at 6:14
Codingo
3,24331941
suggest improvements |Â
up vote
5
down vote
up vote
5
down vote
Firstly - accept that if this really is the case, it's not okay. Too many programmers take home work with them and stay silent on these issues leaving management in the dark (even if they appear to not be).
You also never want to present a problem without some sort of reasoning or a solution. To do this - communication is key. Not just telling your manager that you're not going to be able to reach a deadline but refining how you communicate it.
If I were in your position I would break down the work into items and put timing, and deadlines around each of them. You can then use this to communicate exactly why the deadline isn't achievable, with hard data that the business can feel comfortable making a decision upon. If you're comfortable doing so (depending on your level and the team) you could even suggest some compromises that could be made (with changes or your own schedule) to help get the project back on track.
Should this not work I often continue to update a worksheet as the project commences sending a weekly (or if necessary daily) summary of the work items that have been completed, any blockers to getting work done and the forecasted schedule.
answered Jul 21 '15 at 6:14
Codingo
3,24331941
Firstly - accept that if this really is the case, it's not okay. Too many programmers take home work with them and stay silent on these issues leaving management in the dark (even if they appear to not be).
You also never want to present a problem without some sort of reasoning or a solution. To do this - communication is key. Not just telling your manager that you're not going to be able to reach a deadline but refining how you communicate it.
If I were in your position I would break down the work into items and put timing, and deadlines around each of them. You can then use this to communicate exactly why the deadline isn't achievable, with hard data that the business can feel comfortable making a decision upon. If you're comfortable doing so (depending on your level and the team) you could even suggest some compromises that could be made (with changes or your own schedule) to help get the project back on track.
Should this not work I often continue to update a worksheet as the project commences sending a weekly (or if necessary daily) summary of the work items that have been completed, any blockers to getting work done and the forecasted schedule.
answered Jul 21 '15 at 6:14
Codingo
3,24331941
answered Jul 21 '15 at 6:14
Codingo
3,24331941
answered Jul 21 '15 at 6:14
Codingo
3,24331941
answered Jul 21 '15 at 6:14
Codingo
3,24331941
3,24331941
suggest improvements |Â
suggest improvements |Â
up vote
2
down vote
First of all, it sounds like your company is abusing concept of deadlines and estimations - estimations are estimations and that is all they are. Nobody, ever should expect for a estimation to fit in a deadline exactly and deadline should have a very reasonable safety buffer over estimation for exactly these situations. Delivering sooner is okay, delivering past the deadline is not.
Amending to the previous answers, and based on my previous experience this might as well be a communication issue for one simple reason - people in management often lack technical skills and understanding, and simply put, they are underestimating the importance of software quality which is a real need in this case apparently, as you stated that a lot of refactoring will be needed. Based on that, you should probably present management with the fact that doing it later will cost more, as technical debt only increases and the problem that already exists will not simply go away if postponed - it will increase in severity as you add more and more complexity to the project, and that increase will be exponential to the point where maintaining the project will suck up huge amount of resources. I don't think a wise management will pass on this if it is absolutely certain they will loose money if this continues in a way that it does.
If this is a inside product, argument that we should actually produce something that works well instead of a half baked cake should pass with flying colors.
If this is a product for some external customer, even more - people usually are reasonable enough to accept extending deadlines if that means the end result will improve by order of magnitude.
Last, but not least, you should figure out why this gross underestimation happened in the first place and place a mechanism from preventing it from happening in the future - were the tech people not involved in estimations? Was something important excluded from the estimations, and if so, why? And if so, why was not the deadline extended after it was proven to be unrealistic?
answered Jul 21 '15 at 21:34
Matiss
369310
suggest improvements |Â
up vote
2
down vote
First of all, it sounds like your company is abusing concept of deadlines and estimations - estimations are estimations and that is all they are. Nobody, ever should expect for a estimation to fit in a deadline exactly and deadline should have a very reasonable safety buffer over estimation for exactly these situations. Delivering sooner is okay, delivering past the deadline is not.
Amending to the previous answers, and based on my previous experience this might as well be a communication issue for one simple reason - people in management often lack technical skills and understanding, and simply put, they are underestimating the importance of software quality which is a real need in this case apparently, as you stated that a lot of refactoring will be needed. Based on that, you should probably present management with the fact that doing it later will cost more, as technical debt only increases and the problem that already exists will not simply go away if postponed - it will increase in severity as you add more and more complexity to the project, and that increase will be exponential to the point where maintaining the project will suck up huge amount of resources. I don't think a wise management will pass on this if it is absolutely certain they will loose money if this continues in a way that it does.
If this is a inside product, argument that we should actually produce something that works well instead of a half baked cake should pass with flying colors.
If this is a product for some external customer, even more - people usually are reasonable enough to accept extending deadlines if that means the end result will improve by order of magnitude.
Last, but not least, you should figure out why this gross underestimation happened in the first place and place a mechanism from preventing it from happening in the future - were the tech people not involved in estimations? Was something important excluded from the estimations, and if so, why? And if so, why was not the deadline extended after it was proven to be unrealistic?
answered Jul 21 '15 at 21:34
Matiss
369310
suggest improvements |Â
up vote
2
down vote
up vote
2
down vote
First of all, it sounds like your company is abusing concept of deadlines and estimations - estimations are estimations and that is all they are. Nobody, ever should expect for a estimation to fit in a deadline exactly and deadline should have a very reasonable safety buffer over estimation for exactly these situations. Delivering sooner is okay, delivering past the deadline is not.
Amending to the previous answers, and based on my previous experience this might as well be a communication issue for one simple reason - people in management often lack technical skills and understanding, and simply put, they are underestimating the importance of software quality which is a real need in this case apparently, as you stated that a lot of refactoring will be needed. Based on that, you should probably present management with the fact that doing it later will cost more, as technical debt only increases and the problem that already exists will not simply go away if postponed - it will increase in severity as you add more and more complexity to the project, and that increase will be exponential to the point where maintaining the project will suck up huge amount of resources. I don't think a wise management will pass on this if it is absolutely certain they will loose money if this continues in a way that it does.
If this is a inside product, argument that we should actually produce something that works well instead of a half baked cake should pass with flying colors.
If this is a product for some external customer, even more - people usually are reasonable enough to accept extending deadlines if that means the end result will improve by order of magnitude.
Last, but not least, you should figure out why this gross underestimation happened in the first place and place a mechanism from preventing it from happening in the future - were the tech people not involved in estimations? Was something important excluded from the estimations, and if so, why? And if so, why was not the deadline extended after it was proven to be unrealistic?
answered Jul 21 '15 at 21:34
Matiss
369310
First of all, it sounds like your company is abusing concept of deadlines and estimations - estimations are estimations and that is all they are. Nobody, ever should expect for a estimation to fit in a deadline exactly and deadline should have a very reasonable safety buffer over estimation for exactly these situations. Delivering sooner is okay, delivering past the deadline is not.
Amending to the previous answers, and based on my previous experience this might as well be a communication issue for one simple reason - people in management often lack technical skills and understanding, and simply put, they are underestimating the importance of software quality which is a real need in this case apparently, as you stated that a lot of refactoring will be needed. Based on that, you should probably present management with the fact that doing it later will cost more, as technical debt only increases and the problem that already exists will not simply go away if postponed - it will increase in severity as you add more and more complexity to the project, and that increase will be exponential to the point where maintaining the project will suck up huge amount of resources. I don't think a wise management will pass on this if it is absolutely certain they will loose money if this continues in a way that it does.
If this is a inside product, argument that we should actually produce something that works well instead of a half baked cake should pass with flying colors.
If this is a product for some external customer, even more - people usually are reasonable enough to accept extending deadlines if that means the end result will improve by order of magnitude.
Last, but not least, you should figure out why this gross underestimation happened in the first place and place a mechanism from preventing it from happening in the future - were the tech people not involved in estimations? Was something important excluded from the estimations, and if so, why? And if so, why was not the deadline extended after it was proven to be unrealistic?
answered Jul 21 '15 at 21:34
Matiss
369310
answered Jul 21 '15 at 21:34
Matiss
369310
answered Jul 21 '15 at 21:34
Matiss
369310
answered Jul 21 '15 at 21:34
Matiss
369310
369310
suggest improvements |Â
suggest improvements |Â
up vote
1
down vote
Sorry, but I think you're approaching the problem from too much of an engineering standpoint. It's easy to just accuse management of not being reasonable especially if they're not technically savvy, but you are losing clients. That is a reality.
Like all emergency situations (severe loss and damage with little time and resources), you have to triage. In your case, it has to happen on both the Refactoring and the Feature/Requirements areas. Get those two in synch if possible. If feature A will help retain the most clients, refactor that part of the code base if necessary. At least limit the refactoring in areas with the least interest to your clients. I realize you may be refactoring generalized areas, utilities or frameworks.
I'm skeptical about this large makeover at a time when clients are not satisfied with your application. Fix what you have to solve their problems. If you can get me across the river, I don't need a new bridge.
suggest improvements |Â
up vote
1
down vote
Sorry, but I think you're approaching the problem from too much of an engineering standpoint. It's easy to just accuse management of not being reasonable especially if they're not technically savvy, but you are losing clients. That is a reality.
Like all emergency situations (severe loss and damage with little time and resources), you have to triage. In your case, it has to happen on both the Refactoring and the Feature/Requirements areas. Get those two in synch if possible. If feature A will help retain the most clients, refactor that part of the code base if necessary. At least limit the refactoring in areas with the least interest to your clients. I realize you may be refactoring generalized areas, utilities or frameworks.
I'm skeptical about this large makeover at a time when clients are not satisfied with your application. Fix what you have to solve their problems. If you can get me across the river, I don't need a new bridge.
suggest improvements |Â
up vote
1
down vote
up vote
1
down vote
Sorry, but I think you're approaching the problem from too much of an engineering standpoint. It's easy to just accuse management of not being reasonable especially if they're not technically savvy, but you are losing clients. That is a reality.
Like all emergency situations (severe loss and damage with little time and resources), you have to triage. In your case, it has to happen on both the Refactoring and the Feature/Requirements areas. Get those two in synch if possible. If feature A will help retain the most clients, refactor that part of the code base if necessary. At least limit the refactoring in areas with the least interest to your clients. I realize you may be refactoring generalized areas, utilities or frameworks.
I'm skeptical about this large makeover at a time when clients are not satisfied with your application. Fix what you have to solve their problems. If you can get me across the river, I don't need a new bridge.
Sorry, but I think you're approaching the problem from too much of an engineering standpoint. It's easy to just accuse management of not being reasonable especially if they're not technically savvy, but you are losing clients. That is a reality.
Like all emergency situations (severe loss and damage with little time and resources), you have to triage. In your case, it has to happen on both the Refactoring and the Feature/Requirements areas. Get those two in synch if possible. If feature A will help retain the most clients, refactor that part of the code base if necessary. At least limit the refactoring in areas with the least interest to your clients. I realize you may be refactoring generalized areas, utilities or frameworks.
I'm skeptical about this large makeover at a time when clients are not satisfied with your application. Fix what you have to solve their problems. If you can get me across the river, I don't need a new bridge.
answered Jul 21 '15 at 15:40
user8365
suggest improvements |Â
suggest improvements |Â
3
welcome to the world of programming. This happens to most of us. The only possible way to handle this situation is by increasing your strengths, having a good history of previous "realistic" dead lines and clearly communicating how much you will be able to do in given time.
– Amit
Jul 21 '15 at 5:39
The other answer is to figure out how much can be deferred until after the deadline. Do a quich-and-dirty adapti9n now, then come back and do the clean refactorings later. This is software engineering, not computer science; "on time and under budget" sometimes legitimately trumps "but it'll cost us less in the long run if...". Quoting Steve Bois: " Make it work. Make it good. Make it great." In that order.
– keshlam
Jul 21 '15 at 6:02
4
@keshlam: although the real world almost invariably stops at "Make it work" :)
– Juha Untinen
Jul 21 '15 at 6:58
1
Refactoring is done to make your code easier to maintain in future. Clearly the present is much higher priority then the future in your company, so yes you should drop the refactoring. You need to communicate a better reason to your managers why the deadlines won't be met
– cowls
Jul 21 '15 at 7:29
3
Refactoring may be needed right now, because it may be just impossible to make the old code work with the new features. If the existing code is bad enough, refactoring can be cheaper in the short run.
– gnasher729
Jul 21 '15 at 10:40