Mixing
How to deal with team leader who doesn't want to redesign? [closed]
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
0
down vote
favorite
I work in software development in an industry which is very "nichy". What I mean is that persons outside of this industry often do not understand why you would even use management software.
Anyway, I'm on a team that is rewriting a VB6 program into VB.NET. The problem is that the team leader is the author of the VB program and he basically is trying to recreate in .Net what he already has in VB6.
The existing program is quite buggy and needs much re-design in both the database and the front end, but the leader won't allow. And the management above him does not seem to understand our problem.
How can I convince the team leader and other management that redesign is needed?
teamwork
edited Jun 16 '16 at 19:01
DJClayworth
40.7k886146
asked Jun 16 '16 at 14:10
J Long
92
closed as unclear what you're asking by Dawny33, paparazzo, Lilienthal♦, Richard U, jcmeloni Jun 17 '16 at 15:26
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
 |Â
show 9 more comments
up vote
0
down vote
favorite
I work in software development in an industry which is very "nichy". What I mean is that persons outside of this industry often do not understand why you would even use management software.
Anyway, I'm on a team that is rewriting a VB6 program into VB.NET. The problem is that the team leader is the author of the VB program and he basically is trying to recreate in .Net what he already has in VB6.
The existing program is quite buggy and needs much re-design in both the database and the front end, but the leader won't allow. And the management above him does not seem to understand our problem.
How can I convince the team leader and other management that redesign is needed?
teamwork
edited Jun 16 '16 at 19:01
DJClayworth
40.7k886146
asked Jun 16 '16 at 14:10
J Long
92
closed as unclear what you're asking by Dawny33, paparazzo, Lilienthal♦, Richard U, jcmeloni Jun 17 '16 at 15:26
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
2
This might be more of a question for programmers.stackexchange.com. But please ask it without the assumption that you are right and the project leader is wrong,
– Philipp
Jun 16 '16 at 14:39
4
@Philipp: We don't field questions about people problems or "convince my boss/coworker" at Programmers, and the OP hasn't provided enough detail about the project to make this a software design-related question, or even answerable for that matter.
– Robert Harvey
Jun 16 '16 at 14:50
1
@Philipp this would not be a good question at Programmers
– user16626
Jun 16 '16 at 15:29
1
@JLong It is not clear that a redesign is needed and therefore it is difficult to answer with practical help. Are you aware of this: joelonsoftware.com/articles/fog0000000069.html
– Marv Mills
Jun 16 '16 at 16:43
1
Easiest way is to be promoted into a position of authority, otherwise you don't usually get to tell the bosses what to do.
– Kilisi
Jun 16 '16 at 19:09
 |Â
show 9 more comments
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I work in software development in an industry which is very "nichy". What I mean is that persons outside of this industry often do not understand why you would even use management software.
Anyway, I'm on a team that is rewriting a VB6 program into VB.NET. The problem is that the team leader is the author of the VB program and he basically is trying to recreate in .Net what he already has in VB6.
The existing program is quite buggy and needs much re-design in both the database and the front end, but the leader won't allow. And the management above him does not seem to understand our problem.
How can I convince the team leader and other management that redesign is needed?
teamwork
edited Jun 16 '16 at 19:01
DJClayworth
40.7k886146
asked Jun 16 '16 at 14:10
J Long
92
I work in software development in an industry which is very "nichy". What I mean is that persons outside of this industry often do not understand why you would even use management software.
Anyway, I'm on a team that is rewriting a VB6 program into VB.NET. The problem is that the team leader is the author of the VB program and he basically is trying to recreate in .Net what he already has in VB6.
The existing program is quite buggy and needs much re-design in both the database and the front end, but the leader won't allow. And the management above him does not seem to understand our problem.
How can I convince the team leader and other management that redesign is needed?
teamwork
edited Jun 16 '16 at 19:01
DJClayworth
40.7k886146
asked Jun 16 '16 at 14:10
J Long
92
edited Jun 16 '16 at 19:01
DJClayworth
40.7k886146
edited Jun 16 '16 at 19:01
DJClayworth
40.7k886146
edited Jun 16 '16 at 19:01
DJClayworth
40.7k886146
40.7k886146
asked Jun 16 '16 at 14:10
J Long
92
asked Jun 16 '16 at 14:10
J Long
92
asked Jun 16 '16 at 14:10
J Long
92
92
closed as unclear what you're asking by Dawny33, paparazzo, Lilienthal♦, Richard U, jcmeloni Jun 17 '16 at 15:26
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
closed as unclear what you're asking by Dawny33, paparazzo, Lilienthal♦, Richard U, jcmeloni Jun 17 '16 at 15:26
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
2
This might be more of a question for programmers.stackexchange.com. But please ask it without the assumption that you are right and the project leader is wrong,
– Philipp
Jun 16 '16 at 14:39
4
@Philipp: We don't field questions about people problems or "convince my boss/coworker" at Programmers, and the OP hasn't provided enough detail about the project to make this a software design-related question, or even answerable for that matter.
– Robert Harvey
Jun 16 '16 at 14:50
1
@Philipp this would not be a good question at Programmers
– user16626
Jun 16 '16 at 15:29
1
@JLong It is not clear that a redesign is needed and therefore it is difficult to answer with practical help. Are you aware of this: joelonsoftware.com/articles/fog0000000069.html
– Marv Mills
Jun 16 '16 at 16:43
1
Easiest way is to be promoted into a position of authority, otherwise you don't usually get to tell the bosses what to do.
– Kilisi
Jun 16 '16 at 19:09
 |Â
show 9 more comments
2
This might be more of a question for programmers.stackexchange.com. But please ask it without the assumption that you are right and the project leader is wrong,
– Philipp
Jun 16 '16 at 14:39
4
@Philipp: We don't field questions about people problems or "convince my boss/coworker" at Programmers, and the OP hasn't provided enough detail about the project to make this a software design-related question, or even answerable for that matter.
– Robert Harvey
Jun 16 '16 at 14:50
1
@Philipp this would not be a good question at Programmers
– user16626
Jun 16 '16 at 15:29
1
@JLong It is not clear that a redesign is needed and therefore it is difficult to answer with practical help. Are you aware of this: joelonsoftware.com/articles/fog0000000069.html
– Marv Mills
Jun 16 '16 at 16:43
1
Easiest way is to be promoted into a position of authority, otherwise you don't usually get to tell the bosses what to do.
– Kilisi
Jun 16 '16 at 19:09
2
2
This might be more of a question for programmers.stackexchange.com. But please ask it without the assumption that you are right and the project leader is wrong,
– Philipp
Jun 16 '16 at 14:39
This might be more of a question for programmers.stackexchange.com. But please ask it without the assumption that you are right and the project leader is wrong,
– Philipp
Jun 16 '16 at 14:39
4
4
@Philipp: We don't field questions about people problems or "convince my boss/coworker" at Programmers, and the OP hasn't provided enough detail about the project to make this a software design-related question, or even answerable for that matter.
– Robert Harvey
Jun 16 '16 at 14:50
@Philipp: We don't field questions about people problems or "convince my boss/coworker" at Programmers, and the OP hasn't provided enough detail about the project to make this a software design-related question, or even answerable for that matter.
– Robert Harvey
Jun 16 '16 at 14:50
1
1
@Philipp this would not be a good question at Programmers
– user16626
Jun 16 '16 at 15:29
@Philipp this would not be a good question at Programmers
– user16626
Jun 16 '16 at 15:29
1
1
@JLong It is not clear that a redesign is needed and therefore it is difficult to answer with practical help. Are you aware of this: joelonsoftware.com/articles/fog0000000069.html
– Marv Mills
Jun 16 '16 at 16:43
@JLong It is not clear that a redesign is needed and therefore it is difficult to answer with practical help. Are you aware of this: joelonsoftware.com/articles/fog0000000069.html
– Marv Mills
Jun 16 '16 at 16:43
1
1
Easiest way is to be promoted into a position of authority, otherwise you don't usually get to tell the bosses what to do.
– Kilisi
Jun 16 '16 at 19:09
Easiest way is to be promoted into a position of authority, otherwise you don't usually get to tell the bosses what to do.
– Kilisi
Jun 16 '16 at 19:09
 |Â
show 9 more comments
5 Answers
5
active
oldest
votes
up vote
20
down vote
accepted
It's not clear that a major redesign right now is correct.
It's usually far less work to mechanistically duplicate the same functionality than it would be to redesign the application at the same time, and that is especially true when moving between two similar languages.*
Even if there are big design flaws, there are also big risks to making changes. Changing the front end may upset/confuse users and lead to more training. Changing the data may have implications for whoever is using it. And then there is the effort required for the redesign.
Porting a flawed design in a different language/environment might be perfectly defensible, if the effort for this is low compared to a redesign.
Take an incremental approach to change, focusing on specifics.
The argument "this application is bad and flawed" may be true, but it doesn't work well when your team leader wrote the application. You aren't going to win any support that way.
Instead, identify specific things that could change. Propose something concrete, and highlight the benefit (rather than the flaw of the current design).
Start with changes that are lower risk (less disruptive to the current design) and as people see the benefit, you might get them listening to the bigger ideas that you have about what could change.
*Whether VB6 and VB.NET are versions of the same language is debated, so I have removed this claim, but clearly the two have a lot in common.
2
+1 very thorough. Almost all code is buggy and flawed as we often face tight deadlines and unrealistic expectations. I once worked at a shop where we had statuses of "done" and "done done". "done" meant a usable product, nothing more. If it could get next door via a route that took you downtown, so be it, so long as you wound up where you needed to be. Then there was "done done" where everything was neat and worked well. In many cases, nothing ever goes beyond "done". it sounds like that's where this project needs to be and "done done" would be out of scope
– Richard U
Jun 16 '16 at 14:49
Thanks for the edit. This is my first question ever on this site so I'm learning.
– J Long
Jun 16 '16 at 14:54
@RichardU, some day I hope to have a project that gets "done done"!
– user45590
Jun 16 '16 at 15:05
1
Since VB6 and VB.NET are variants of the same language... what?
– deviantfan
Jun 16 '16 at 19:12
2
As @deviantfan .. VB6 and VB.NET are two completely different languages that share a name for marketing reasons
– Carson63000
Jun 17 '16 at 4:06
 |Â
show 2 more comments
up vote
6
down vote
We're putting one foot over in StackOverflow, here, but here goes:
- Is it your decision? If not, follow your instructions. I've done this jump (VB6 to VB.NET) a few times on old projects. It's boring, but it has to be done. If the business has decided that this is all they want to do, then that's all they're going //TODO: (don't fix that, it's a pun)
- Are the bugs actually code not working properly, or poorly implemented business requirements? If it's code not working properly, throw a unit testing framework at it and prove it. If it's business requirements, prepare a "Risk Analysis" document for management, and let them make the decision.
Then, have ready a project plan for "fixing" it, especially resource requirements. Don't submit it. If they take your risk analysis seriously, they'll come asking for it. If they don't, well, you're going to need sample work for that resume some day.
answered Jun 16 '16 at 19:18
Wesley Long
44.6k15100159
suggest improvements |Â
up vote
1
down vote
Metrics
If you want to go to management with a proposal, a good starting point is showing them how redesigning the system will save them money. This is assuming you have the data to pull from and it's reliable.
A simple example would be tallying up the amount of time each developer has spent fixing bugs, the amount of time quality assurance spends testing new features that are rejected because of bugs (known as "churn"), and the amount of time customer service spends helping customers experiencing the unstable features of the software, etc, etc. Turn that in to a dollar figure over a set span of time. This is how much the software is costing your company. Build a case for rewriting the whole thing from this figure.
answered Jun 16 '16 at 19:17
bluescores
45235
suggest improvements |Â
up vote
1
down vote
Before you have the argument, be able to clearly articulate the pros and cons of both sides. If you don't seen any value at all to the other side, you probably don't have the ammunition you need to win the argument - these debates are never one sided.
Here's some of the basics in a tradeoff like this:
Pros for Redesign:
- we have the opportunity to learn from our mistake
- it will save time in the long run (not having to fix the bugs from before, not paying for maintenance cost)
- it (may) save money right now - easier to fix and upgrade than upgrade and fix later - note, this is NOT universal - it takes serious knowledge and research on the system to make this case adequately. If your boss is the subject matter expert on the system and the language, he may well have far more insight on this than you - you should ask him to give you his estimates on tradeoff costs here.
Cons for Redesign:
- we don't know what bugs we will create or how they will impact us
- we open ourselves up to scope creep - when we say "better design" we usually also mean it leads to a better functional spec. That cracks the cover, and people may come running to request other "design improvements" that are really new features.
- we don't have time - better/more efficient does not necessarily mean faster.
Pros for Direct Translation of Design:
- (often) - smaller cost - if it's possible, it usually takes less time to update exactly the code you have than to figure out how to redesign it
- we know the failings - we know the failings, we haven't gotten too bitten by them yet, we have found ways to work around what does cause problems. - this is a serious cost savings in some circumstances
Cons for Direct Translation of Design:
- has known bugs
- has extensibility limitations
- people hate it - yes, it's subjective, but if it's a retention factor, this is a real reason to avoid very very old code.
After this you still want to be open to the environmental conditions - and there may be conditions that you don't know about - for example, I've been told to do what I considered a poor design because it was the FAST design and we knew we needed to hit a specific deadline. Or I did a suboptimal design because it was only needed for a short time frame. There's no perfect on these choices - the strategy has to fit the business conditions as well as the technical view.
I'll say honestly that every engineer I've managed has at one time or another wanted to redesign the system utterly because it was too buggy (not just 1 system, I've managed people for 10 years, in 3 companies, with probably 20 different software codebases, depending on how you count them - I've wanted to redesign ALL those codebases at least once when working on them... including code that I wrote and designed entirely by myself!). Only in a handful of cases could I grant that wish, and only in a subset of THOSE cases, did granting the wish result in a wonderful product that was provably better than what we had before.
answered Jun 16 '16 at 20:03
bethlakshmi
70.3k4136277
suggest improvements |Â
up vote
0
down vote
For the question whether a redesign or not is a good idea, go to programmers.stackexchange. You have your opinion, but there are a lot of things speaking against it. For example, do you really think you can rewrite everything without introducing new, unknown bugs?
You are not the decision maker. You are not necessarily the one who knows best. Actually, you are not even likely to be the one who knows best. There is a limited number of hours of work that you can perform, and the company won't ask if a redesign is a good use of your work time, but whether it is the best use. (And even whether it is a good use of your work time is debatable). If you are in conflict with your team leader, make sure that doesn't affect your ability to do the tasks that you are asked to do.
answered Jun 17 '16 at 9:16
gnasher729
70.6k31131220
suggest improvements |Â
5 Answers
5
active
oldest
votes
5 Answers
5
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
20
down vote
accepted
It's not clear that a major redesign right now is correct.
It's usually far less work to mechanistically duplicate the same functionality than it would be to redesign the application at the same time, and that is especially true when moving between two similar languages.*
Even if there are big design flaws, there are also big risks to making changes. Changing the front end may upset/confuse users and lead to more training. Changing the data may have implications for whoever is using it. And then there is the effort required for the redesign.
Porting a flawed design in a different language/environment might be perfectly defensible, if the effort for this is low compared to a redesign.
Take an incremental approach to change, focusing on specifics.
The argument "this application is bad and flawed" may be true, but it doesn't work well when your team leader wrote the application. You aren't going to win any support that way.
Instead, identify specific things that could change. Propose something concrete, and highlight the benefit (rather than the flaw of the current design).
Start with changes that are lower risk (less disruptive to the current design) and as people see the benefit, you might get them listening to the bigger ideas that you have about what could change.
*Whether VB6 and VB.NET are versions of the same language is debated, so I have removed this claim, but clearly the two have a lot in common.
2
+1 very thorough. Almost all code is buggy and flawed as we often face tight deadlines and unrealistic expectations. I once worked at a shop where we had statuses of "done" and "done done". "done" meant a usable product, nothing more. If it could get next door via a route that took you downtown, so be it, so long as you wound up where you needed to be. Then there was "done done" where everything was neat and worked well. In many cases, nothing ever goes beyond "done". it sounds like that's where this project needs to be and "done done" would be out of scope
– Richard U
Jun 16 '16 at 14:49
Thanks for the edit. This is my first question ever on this site so I'm learning.
– J Long
Jun 16 '16 at 14:54
@RichardU, some day I hope to have a project that gets "done done"!
– user45590
Jun 16 '16 at 15:05
1
Since VB6 and VB.NET are variants of the same language... what?
– deviantfan
Jun 16 '16 at 19:12
2
As @deviantfan .. VB6 and VB.NET are two completely different languages that share a name for marketing reasons
– Carson63000
Jun 17 '16 at 4:06
 |Â
show 2 more comments
up vote
20
down vote
accepted
It's not clear that a major redesign right now is correct.
It's usually far less work to mechanistically duplicate the same functionality than it would be to redesign the application at the same time, and that is especially true when moving between two similar languages.*
Even if there are big design flaws, there are also big risks to making changes. Changing the front end may upset/confuse users and lead to more training. Changing the data may have implications for whoever is using it. And then there is the effort required for the redesign.
Porting a flawed design in a different language/environment might be perfectly defensible, if the effort for this is low compared to a redesign.
Take an incremental approach to change, focusing on specifics.
The argument "this application is bad and flawed" may be true, but it doesn't work well when your team leader wrote the application. You aren't going to win any support that way.
Instead, identify specific things that could change. Propose something concrete, and highlight the benefit (rather than the flaw of the current design).
Start with changes that are lower risk (less disruptive to the current design) and as people see the benefit, you might get them listening to the bigger ideas that you have about what could change.
*Whether VB6 and VB.NET are versions of the same language is debated, so I have removed this claim, but clearly the two have a lot in common.
2
+1 very thorough. Almost all code is buggy and flawed as we often face tight deadlines and unrealistic expectations. I once worked at a shop where we had statuses of "done" and "done done". "done" meant a usable product, nothing more. If it could get next door via a route that took you downtown, so be it, so long as you wound up where you needed to be. Then there was "done done" where everything was neat and worked well. In many cases, nothing ever goes beyond "done". it sounds like that's where this project needs to be and "done done" would be out of scope
– Richard U
Jun 16 '16 at 14:49
Thanks for the edit. This is my first question ever on this site so I'm learning.
– J Long
Jun 16 '16 at 14:54
@RichardU, some day I hope to have a project that gets "done done"!
– user45590
Jun 16 '16 at 15:05
1
Since VB6 and VB.NET are variants of the same language... what?
– deviantfan
Jun 16 '16 at 19:12
2
As @deviantfan .. VB6 and VB.NET are two completely different languages that share a name for marketing reasons
– Carson63000
Jun 17 '16 at 4:06
 |Â
show 2 more comments
up vote
20
down vote
accepted
up vote
20
down vote
accepted
It's not clear that a major redesign right now is correct.
It's usually far less work to mechanistically duplicate the same functionality than it would be to redesign the application at the same time, and that is especially true when moving between two similar languages.*
Even if there are big design flaws, there are also big risks to making changes. Changing the front end may upset/confuse users and lead to more training. Changing the data may have implications for whoever is using it. And then there is the effort required for the redesign.
Porting a flawed design in a different language/environment might be perfectly defensible, if the effort for this is low compared to a redesign.
Take an incremental approach to change, focusing on specifics.
The argument "this application is bad and flawed" may be true, but it doesn't work well when your team leader wrote the application. You aren't going to win any support that way.
Instead, identify specific things that could change. Propose something concrete, and highlight the benefit (rather than the flaw of the current design).
Start with changes that are lower risk (less disruptive to the current design) and as people see the benefit, you might get them listening to the bigger ideas that you have about what could change.
*Whether VB6 and VB.NET are versions of the same language is debated, so I have removed this claim, but clearly the two have a lot in common.
It's not clear that a major redesign right now is correct.
It's usually far less work to mechanistically duplicate the same functionality than it would be to redesign the application at the same time, and that is especially true when moving between two similar languages.*
Even if there are big design flaws, there are also big risks to making changes. Changing the front end may upset/confuse users and lead to more training. Changing the data may have implications for whoever is using it. And then there is the effort required for the redesign.
Porting a flawed design in a different language/environment might be perfectly defensible, if the effort for this is low compared to a redesign.
Take an incremental approach to change, focusing on specifics.
The argument "this application is bad and flawed" may be true, but it doesn't work well when your team leader wrote the application. You aren't going to win any support that way.
Instead, identify specific things that could change. Propose something concrete, and highlight the benefit (rather than the flaw of the current design).
Start with changes that are lower risk (less disruptive to the current design) and as people see the benefit, you might get them listening to the bigger ideas that you have about what could change.
*Whether VB6 and VB.NET are versions of the same language is debated, so I have removed this claim, but clearly the two have a lot in common.
edited Jun 17 '16 at 7:12
answered Jun 16 '16 at 14:29
user45590
2
+1 very thorough. Almost all code is buggy and flawed as we often face tight deadlines and unrealistic expectations. I once worked at a shop where we had statuses of "done" and "done done". "done" meant a usable product, nothing more. If it could get next door via a route that took you downtown, so be it, so long as you wound up where you needed to be. Then there was "done done" where everything was neat and worked well. In many cases, nothing ever goes beyond "done". it sounds like that's where this project needs to be and "done done" would be out of scope
– Richard U
Jun 16 '16 at 14:49
Thanks for the edit. This is my first question ever on this site so I'm learning.
– J Long
Jun 16 '16 at 14:54
@RichardU, some day I hope to have a project that gets "done done"!
– user45590
Jun 16 '16 at 15:05
1
Since VB6 and VB.NET are variants of the same language... what?
– deviantfan
Jun 16 '16 at 19:12
2
As @deviantfan .. VB6 and VB.NET are two completely different languages that share a name for marketing reasons
– Carson63000
Jun 17 '16 at 4:06
 |Â
show 2 more comments
2
+1 very thorough. Almost all code is buggy and flawed as we often face tight deadlines and unrealistic expectations. I once worked at a shop where we had statuses of "done" and "done done". "done" meant a usable product, nothing more. If it could get next door via a route that took you downtown, so be it, so long as you wound up where you needed to be. Then there was "done done" where everything was neat and worked well. In many cases, nothing ever goes beyond "done". it sounds like that's where this project needs to be and "done done" would be out of scope
– Richard U
Jun 16 '16 at 14:49
Thanks for the edit. This is my first question ever on this site so I'm learning.
– J Long
Jun 16 '16 at 14:54
@RichardU, some day I hope to have a project that gets "done done"!
– user45590
Jun 16 '16 at 15:05
1
Since VB6 and VB.NET are variants of the same language... what?
– deviantfan
Jun 16 '16 at 19:12
2
As @deviantfan .. VB6 and VB.NET are two completely different languages that share a name for marketing reasons
– Carson63000
Jun 17 '16 at 4:06
2
2
+1 very thorough. Almost all code is buggy and flawed as we often face tight deadlines and unrealistic expectations. I once worked at a shop where we had statuses of "done" and "done done". "done" meant a usable product, nothing more. If it could get next door via a route that took you downtown, so be it, so long as you wound up where you needed to be. Then there was "done done" where everything was neat and worked well. In many cases, nothing ever goes beyond "done". it sounds like that's where this project needs to be and "done done" would be out of scope
– Richard U
Jun 16 '16 at 14:49
+1 very thorough. Almost all code is buggy and flawed as we often face tight deadlines and unrealistic expectations. I once worked at a shop where we had statuses of "done" and "done done". "done" meant a usable product, nothing more. If it could get next door via a route that took you downtown, so be it, so long as you wound up where you needed to be. Then there was "done done" where everything was neat and worked well. In many cases, nothing ever goes beyond "done". it sounds like that's where this project needs to be and "done done" would be out of scope
– Richard U
Jun 16 '16 at 14:49
Thanks for the edit. This is my first question ever on this site so I'm learning.
– J Long
Jun 16 '16 at 14:54
Thanks for the edit. This is my first question ever on this site so I'm learning.
– J Long
Jun 16 '16 at 14:54
@RichardU, some day I hope to have a project that gets "done done"!
– user45590
Jun 16 '16 at 15:05
@RichardU, some day I hope to have a project that gets "done done"!
– user45590
Jun 16 '16 at 15:05
1
1
Since VB6 and VB.NET are variants of the same language ... what?– deviantfan
Jun 16 '16 at 19:12
Since VB6 and VB.NET are variants of the same language ... what?– deviantfan
Jun 16 '16 at 19:12
2
2
As @deviantfan .. VB6 and VB.NET are two completely different languages that share a name for marketing reasons
– Carson63000
Jun 17 '16 at 4:06
As @deviantfan .. VB6 and VB.NET are two completely different languages that share a name for marketing reasons
– Carson63000
Jun 17 '16 at 4:06
 |Â
show 2 more comments
up vote
6
down vote
We're putting one foot over in StackOverflow, here, but here goes:
- Is it your decision? If not, follow your instructions. I've done this jump (VB6 to VB.NET) a few times on old projects. It's boring, but it has to be done. If the business has decided that this is all they want to do, then that's all they're going //TODO: (don't fix that, it's a pun)
- Are the bugs actually code not working properly, or poorly implemented business requirements? If it's code not working properly, throw a unit testing framework at it and prove it. If it's business requirements, prepare a "Risk Analysis" document for management, and let them make the decision.
Then, have ready a project plan for "fixing" it, especially resource requirements. Don't submit it. If they take your risk analysis seriously, they'll come asking for it. If they don't, well, you're going to need sample work for that resume some day.
answered Jun 16 '16 at 19:18
Wesley Long
44.6k15100159
suggest improvements |Â
up vote
6
down vote
We're putting one foot over in StackOverflow, here, but here goes:
- Is it your decision? If not, follow your instructions. I've done this jump (VB6 to VB.NET) a few times on old projects. It's boring, but it has to be done. If the business has decided that this is all they want to do, then that's all they're going //TODO: (don't fix that, it's a pun)
- Are the bugs actually code not working properly, or poorly implemented business requirements? If it's code not working properly, throw a unit testing framework at it and prove it. If it's business requirements, prepare a "Risk Analysis" document for management, and let them make the decision.
Then, have ready a project plan for "fixing" it, especially resource requirements. Don't submit it. If they take your risk analysis seriously, they'll come asking for it. If they don't, well, you're going to need sample work for that resume some day.
answered Jun 16 '16 at 19:18
Wesley Long
44.6k15100159
suggest improvements |Â
up vote
6
down vote
up vote
6
down vote
We're putting one foot over in StackOverflow, here, but here goes:
- Is it your decision? If not, follow your instructions. I've done this jump (VB6 to VB.NET) a few times on old projects. It's boring, but it has to be done. If the business has decided that this is all they want to do, then that's all they're going //TODO: (don't fix that, it's a pun)
- Are the bugs actually code not working properly, or poorly implemented business requirements? If it's code not working properly, throw a unit testing framework at it and prove it. If it's business requirements, prepare a "Risk Analysis" document for management, and let them make the decision.
Then, have ready a project plan for "fixing" it, especially resource requirements. Don't submit it. If they take your risk analysis seriously, they'll come asking for it. If they don't, well, you're going to need sample work for that resume some day.
answered Jun 16 '16 at 19:18
Wesley Long
44.6k15100159
We're putting one foot over in StackOverflow, here, but here goes:
- Is it your decision? If not, follow your instructions. I've done this jump (VB6 to VB.NET) a few times on old projects. It's boring, but it has to be done. If the business has decided that this is all they want to do, then that's all they're going //TODO: (don't fix that, it's a pun)
- Are the bugs actually code not working properly, or poorly implemented business requirements? If it's code not working properly, throw a unit testing framework at it and prove it. If it's business requirements, prepare a "Risk Analysis" document for management, and let them make the decision.
Then, have ready a project plan for "fixing" it, especially resource requirements. Don't submit it. If they take your risk analysis seriously, they'll come asking for it. If they don't, well, you're going to need sample work for that resume some day.
answered Jun 16 '16 at 19:18
Wesley Long
44.6k15100159
answered Jun 16 '16 at 19:18
Wesley Long
44.6k15100159
answered Jun 16 '16 at 19:18
Wesley Long
44.6k15100159
answered Jun 16 '16 at 19:18
Wesley Long
44.6k15100159
44.6k15100159
suggest improvements |Â
suggest improvements |Â
up vote
1
down vote
Metrics
If you want to go to management with a proposal, a good starting point is showing them how redesigning the system will save them money. This is assuming you have the data to pull from and it's reliable.
A simple example would be tallying up the amount of time each developer has spent fixing bugs, the amount of time quality assurance spends testing new features that are rejected because of bugs (known as "churn"), and the amount of time customer service spends helping customers experiencing the unstable features of the software, etc, etc. Turn that in to a dollar figure over a set span of time. This is how much the software is costing your company. Build a case for rewriting the whole thing from this figure.
answered Jun 16 '16 at 19:17
bluescores
45235
suggest improvements |Â
up vote
1
down vote
Metrics
If you want to go to management with a proposal, a good starting point is showing them how redesigning the system will save them money. This is assuming you have the data to pull from and it's reliable.
A simple example would be tallying up the amount of time each developer has spent fixing bugs, the amount of time quality assurance spends testing new features that are rejected because of bugs (known as "churn"), and the amount of time customer service spends helping customers experiencing the unstable features of the software, etc, etc. Turn that in to a dollar figure over a set span of time. This is how much the software is costing your company. Build a case for rewriting the whole thing from this figure.
answered Jun 16 '16 at 19:17
bluescores
45235
suggest improvements |Â
up vote
1
down vote
up vote
1
down vote
Metrics
If you want to go to management with a proposal, a good starting point is showing them how redesigning the system will save them money. This is assuming you have the data to pull from and it's reliable.
A simple example would be tallying up the amount of time each developer has spent fixing bugs, the amount of time quality assurance spends testing new features that are rejected because of bugs (known as "churn"), and the amount of time customer service spends helping customers experiencing the unstable features of the software, etc, etc. Turn that in to a dollar figure over a set span of time. This is how much the software is costing your company. Build a case for rewriting the whole thing from this figure.
answered Jun 16 '16 at 19:17
bluescores
45235
Metrics
If you want to go to management with a proposal, a good starting point is showing them how redesigning the system will save them money. This is assuming you have the data to pull from and it's reliable.
A simple example would be tallying up the amount of time each developer has spent fixing bugs, the amount of time quality assurance spends testing new features that are rejected because of bugs (known as "churn"), and the amount of time customer service spends helping customers experiencing the unstable features of the software, etc, etc. Turn that in to a dollar figure over a set span of time. This is how much the software is costing your company. Build a case for rewriting the whole thing from this figure.
answered Jun 16 '16 at 19:17
bluescores
45235
answered Jun 16 '16 at 19:17
bluescores
45235
answered Jun 16 '16 at 19:17
bluescores
45235
answered Jun 16 '16 at 19:17
bluescores
45235
45235
suggest improvements |Â
suggest improvements |Â
up vote
1
down vote
Before you have the argument, be able to clearly articulate the pros and cons of both sides. If you don't seen any value at all to the other side, you probably don't have the ammunition you need to win the argument - these debates are never one sided.
Here's some of the basics in a tradeoff like this:
Pros for Redesign:
- we have the opportunity to learn from our mistake
- it will save time in the long run (not having to fix the bugs from before, not paying for maintenance cost)
- it (may) save money right now - easier to fix and upgrade than upgrade and fix later - note, this is NOT universal - it takes serious knowledge and research on the system to make this case adequately. If your boss is the subject matter expert on the system and the language, he may well have far more insight on this than you - you should ask him to give you his estimates on tradeoff costs here.
Cons for Redesign:
- we don't know what bugs we will create or how they will impact us
- we open ourselves up to scope creep - when we say "better design" we usually also mean it leads to a better functional spec. That cracks the cover, and people may come running to request other "design improvements" that are really new features.
- we don't have time - better/more efficient does not necessarily mean faster.
Pros for Direct Translation of Design:
- (often) - smaller cost - if it's possible, it usually takes less time to update exactly the code you have than to figure out how to redesign it
- we know the failings - we know the failings, we haven't gotten too bitten by them yet, we have found ways to work around what does cause problems. - this is a serious cost savings in some circumstances
Cons for Direct Translation of Design:
- has known bugs
- has extensibility limitations
- people hate it - yes, it's subjective, but if it's a retention factor, this is a real reason to avoid very very old code.
After this you still want to be open to the environmental conditions - and there may be conditions that you don't know about - for example, I've been told to do what I considered a poor design because it was the FAST design and we knew we needed to hit a specific deadline. Or I did a suboptimal design because it was only needed for a short time frame. There's no perfect on these choices - the strategy has to fit the business conditions as well as the technical view.
I'll say honestly that every engineer I've managed has at one time or another wanted to redesign the system utterly because it was too buggy (not just 1 system, I've managed people for 10 years, in 3 companies, with probably 20 different software codebases, depending on how you count them - I've wanted to redesign ALL those codebases at least once when working on them... including code that I wrote and designed entirely by myself!). Only in a handful of cases could I grant that wish, and only in a subset of THOSE cases, did granting the wish result in a wonderful product that was provably better than what we had before.
answered Jun 16 '16 at 20:03
bethlakshmi
70.3k4136277
suggest improvements |Â
up vote
1
down vote
Before you have the argument, be able to clearly articulate the pros and cons of both sides. If you don't seen any value at all to the other side, you probably don't have the ammunition you need to win the argument - these debates are never one sided.
Here's some of the basics in a tradeoff like this:
Pros for Redesign:
- we have the opportunity to learn from our mistake
- it will save time in the long run (not having to fix the bugs from before, not paying for maintenance cost)
- it (may) save money right now - easier to fix and upgrade than upgrade and fix later - note, this is NOT universal - it takes serious knowledge and research on the system to make this case adequately. If your boss is the subject matter expert on the system and the language, he may well have far more insight on this than you - you should ask him to give you his estimates on tradeoff costs here.
Cons for Redesign:
- we don't know what bugs we will create or how they will impact us
- we open ourselves up to scope creep - when we say "better design" we usually also mean it leads to a better functional spec. That cracks the cover, and people may come running to request other "design improvements" that are really new features.
- we don't have time - better/more efficient does not necessarily mean faster.
Pros for Direct Translation of Design:
- (often) - smaller cost - if it's possible, it usually takes less time to update exactly the code you have than to figure out how to redesign it
- we know the failings - we know the failings, we haven't gotten too bitten by them yet, we have found ways to work around what does cause problems. - this is a serious cost savings in some circumstances
Cons for Direct Translation of Design:
- has known bugs
- has extensibility limitations
- people hate it - yes, it's subjective, but if it's a retention factor, this is a real reason to avoid very very old code.
After this you still want to be open to the environmental conditions - and there may be conditions that you don't know about - for example, I've been told to do what I considered a poor design because it was the FAST design and we knew we needed to hit a specific deadline. Or I did a suboptimal design because it was only needed for a short time frame. There's no perfect on these choices - the strategy has to fit the business conditions as well as the technical view.
I'll say honestly that every engineer I've managed has at one time or another wanted to redesign the system utterly because it was too buggy (not just 1 system, I've managed people for 10 years, in 3 companies, with probably 20 different software codebases, depending on how you count them - I've wanted to redesign ALL those codebases at least once when working on them... including code that I wrote and designed entirely by myself!). Only in a handful of cases could I grant that wish, and only in a subset of THOSE cases, did granting the wish result in a wonderful product that was provably better than what we had before.
answered Jun 16 '16 at 20:03
bethlakshmi
70.3k4136277
suggest improvements |Â
up vote
1
down vote
up vote
1
down vote
Before you have the argument, be able to clearly articulate the pros and cons of both sides. If you don't seen any value at all to the other side, you probably don't have the ammunition you need to win the argument - these debates are never one sided.
Here's some of the basics in a tradeoff like this:
Pros for Redesign:
- we have the opportunity to learn from our mistake
- it will save time in the long run (not having to fix the bugs from before, not paying for maintenance cost)
- it (may) save money right now - easier to fix and upgrade than upgrade and fix later - note, this is NOT universal - it takes serious knowledge and research on the system to make this case adequately. If your boss is the subject matter expert on the system and the language, he may well have far more insight on this than you - you should ask him to give you his estimates on tradeoff costs here.
Cons for Redesign:
- we don't know what bugs we will create or how they will impact us
- we open ourselves up to scope creep - when we say "better design" we usually also mean it leads to a better functional spec. That cracks the cover, and people may come running to request other "design improvements" that are really new features.
- we don't have time - better/more efficient does not necessarily mean faster.
Pros for Direct Translation of Design:
- (often) - smaller cost - if it's possible, it usually takes less time to update exactly the code you have than to figure out how to redesign it
- we know the failings - we know the failings, we haven't gotten too bitten by them yet, we have found ways to work around what does cause problems. - this is a serious cost savings in some circumstances
Cons for Direct Translation of Design:
- has known bugs
- has extensibility limitations
- people hate it - yes, it's subjective, but if it's a retention factor, this is a real reason to avoid very very old code.
After this you still want to be open to the environmental conditions - and there may be conditions that you don't know about - for example, I've been told to do what I considered a poor design because it was the FAST design and we knew we needed to hit a specific deadline. Or I did a suboptimal design because it was only needed for a short time frame. There's no perfect on these choices - the strategy has to fit the business conditions as well as the technical view.
I'll say honestly that every engineer I've managed has at one time or another wanted to redesign the system utterly because it was too buggy (not just 1 system, I've managed people for 10 years, in 3 companies, with probably 20 different software codebases, depending on how you count them - I've wanted to redesign ALL those codebases at least once when working on them... including code that I wrote and designed entirely by myself!). Only in a handful of cases could I grant that wish, and only in a subset of THOSE cases, did granting the wish result in a wonderful product that was provably better than what we had before.
answered Jun 16 '16 at 20:03
bethlakshmi
70.3k4136277
Before you have the argument, be able to clearly articulate the pros and cons of both sides. If you don't seen any value at all to the other side, you probably don't have the ammunition you need to win the argument - these debates are never one sided.
Here's some of the basics in a tradeoff like this:
Pros for Redesign:
- we have the opportunity to learn from our mistake
- it will save time in the long run (not having to fix the bugs from before, not paying for maintenance cost)
- it (may) save money right now - easier to fix and upgrade than upgrade and fix later - note, this is NOT universal - it takes serious knowledge and research on the system to make this case adequately. If your boss is the subject matter expert on the system and the language, he may well have far more insight on this than you - you should ask him to give you his estimates on tradeoff costs here.
Cons for Redesign:
- we don't know what bugs we will create or how they will impact us
- we open ourselves up to scope creep - when we say "better design" we usually also mean it leads to a better functional spec. That cracks the cover, and people may come running to request other "design improvements" that are really new features.
- we don't have time - better/more efficient does not necessarily mean faster.
Pros for Direct Translation of Design:
- (often) - smaller cost - if it's possible, it usually takes less time to update exactly the code you have than to figure out how to redesign it
- we know the failings - we know the failings, we haven't gotten too bitten by them yet, we have found ways to work around what does cause problems. - this is a serious cost savings in some circumstances
Cons for Direct Translation of Design:
- has known bugs
- has extensibility limitations
- people hate it - yes, it's subjective, but if it's a retention factor, this is a real reason to avoid very very old code.
After this you still want to be open to the environmental conditions - and there may be conditions that you don't know about - for example, I've been told to do what I considered a poor design because it was the FAST design and we knew we needed to hit a specific deadline. Or I did a suboptimal design because it was only needed for a short time frame. There's no perfect on these choices - the strategy has to fit the business conditions as well as the technical view.
I'll say honestly that every engineer I've managed has at one time or another wanted to redesign the system utterly because it was too buggy (not just 1 system, I've managed people for 10 years, in 3 companies, with probably 20 different software codebases, depending on how you count them - I've wanted to redesign ALL those codebases at least once when working on them... including code that I wrote and designed entirely by myself!). Only in a handful of cases could I grant that wish, and only in a subset of THOSE cases, did granting the wish result in a wonderful product that was provably better than what we had before.
answered Jun 16 '16 at 20:03
bethlakshmi
70.3k4136277
answered Jun 16 '16 at 20:03
bethlakshmi
70.3k4136277
answered Jun 16 '16 at 20:03
bethlakshmi
70.3k4136277
answered Jun 16 '16 at 20:03
bethlakshmi
70.3k4136277
70.3k4136277
suggest improvements |Â
suggest improvements |Â
up vote
0
down vote
For the question whether a redesign or not is a good idea, go to programmers.stackexchange. You have your opinion, but there are a lot of things speaking against it. For example, do you really think you can rewrite everything without introducing new, unknown bugs?
You are not the decision maker. You are not necessarily the one who knows best. Actually, you are not even likely to be the one who knows best. There is a limited number of hours of work that you can perform, and the company won't ask if a redesign is a good use of your work time, but whether it is the best use. (And even whether it is a good use of your work time is debatable). If you are in conflict with your team leader, make sure that doesn't affect your ability to do the tasks that you are asked to do.
answered Jun 17 '16 at 9:16
gnasher729
70.6k31131220
suggest improvements |Â
up vote
0
down vote
For the question whether a redesign or not is a good idea, go to programmers.stackexchange. You have your opinion, but there are a lot of things speaking against it. For example, do you really think you can rewrite everything without introducing new, unknown bugs?
You are not the decision maker. You are not necessarily the one who knows best. Actually, you are not even likely to be the one who knows best. There is a limited number of hours of work that you can perform, and the company won't ask if a redesign is a good use of your work time, but whether it is the best use. (And even whether it is a good use of your work time is debatable). If you are in conflict with your team leader, make sure that doesn't affect your ability to do the tasks that you are asked to do.
answered Jun 17 '16 at 9:16
gnasher729
70.6k31131220
suggest improvements |Â
up vote
0
down vote
up vote
0
down vote
For the question whether a redesign or not is a good idea, go to programmers.stackexchange. You have your opinion, but there are a lot of things speaking against it. For example, do you really think you can rewrite everything without introducing new, unknown bugs?
You are not the decision maker. You are not necessarily the one who knows best. Actually, you are not even likely to be the one who knows best. There is a limited number of hours of work that you can perform, and the company won't ask if a redesign is a good use of your work time, but whether it is the best use. (And even whether it is a good use of your work time is debatable). If you are in conflict with your team leader, make sure that doesn't affect your ability to do the tasks that you are asked to do.
answered Jun 17 '16 at 9:16
gnasher729
70.6k31131220
For the question whether a redesign or not is a good idea, go to programmers.stackexchange. You have your opinion, but there are a lot of things speaking against it. For example, do you really think you can rewrite everything without introducing new, unknown bugs?
You are not the decision maker. You are not necessarily the one who knows best. Actually, you are not even likely to be the one who knows best. There is a limited number of hours of work that you can perform, and the company won't ask if a redesign is a good use of your work time, but whether it is the best use. (And even whether it is a good use of your work time is debatable). If you are in conflict with your team leader, make sure that doesn't affect your ability to do the tasks that you are asked to do.
answered Jun 17 '16 at 9:16
gnasher729
70.6k31131220
answered Jun 17 '16 at 9:16
gnasher729
70.6k31131220
answered Jun 17 '16 at 9:16
gnasher729
70.6k31131220
answered Jun 17 '16 at 9:16
gnasher729
70.6k31131220
70.6k31131220
suggest improvements |Â
suggest improvements |Â
2
This might be more of a question for programmers.stackexchange.com. But please ask it without the assumption that you are right and the project leader is wrong,
– Philipp
Jun 16 '16 at 14:39
4
@Philipp: We don't field questions about people problems or "convince my boss/coworker" at Programmers, and the OP hasn't provided enough detail about the project to make this a software design-related question, or even answerable for that matter.
– Robert Harvey
Jun 16 '16 at 14:50
1
@Philipp this would not be a good question at Programmers
– user16626
Jun 16 '16 at 15:29
1
@JLong It is not clear that a redesign is needed and therefore it is difficult to answer with practical help. Are you aware of this: joelonsoftware.com/articles/fog0000000069.html
– Marv Mills
Jun 16 '16 at 16:43
1
Easiest way is to be promoted into a position of authority, otherwise you don't usually get to tell the bosses what to do.
– Kilisi
Jun 16 '16 at 19:09