Mixing
How to make young software engineers improve the quality of their output?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
9
down vote
favorite
During our last project, our team composed of young software engineers made a product which contains much more bugs than other teams. We have a senior engineer who was part of the team, but isn't much involved in the development process as he has been promoted to manager. He just reviewed the team's code for the first time and found a lot of issues.
This team has shown strong capabilities in the past, but the result of our last project got me worried.
What the team members said about this last project:
- It is more complicated than our previous ones: lots of requirement change, complex interactions with the database, complex UI, new technologies...
- Not enough time, too much pressure
- Hard to understand the requirement (however we made sure everybody understands the requirements thoroughly during the project)
I trust my team, they are really good people. What can I do to make them improve their output?
project-management
asked Jul 1 '15 at 2:54
Brainless
180210
 |Â
show 7 more comments
up vote
9
down vote
favorite
During our last project, our team composed of young software engineers made a product which contains much more bugs than other teams. We have a senior engineer who was part of the team, but isn't much involved in the development process as he has been promoted to manager. He just reviewed the team's code for the first time and found a lot of issues.
This team has shown strong capabilities in the past, but the result of our last project got me worried.
What the team members said about this last project:
- It is more complicated than our previous ones: lots of requirement change, complex interactions with the database, complex UI, new technologies...
- Not enough time, too much pressure
- Hard to understand the requirement (however we made sure everybody understands the requirements thoroughly during the project)
I trust my team, they are really good people. What can I do to make them improve their output?
project-management
asked Jul 1 '15 at 2:54
Brainless
180210
6
How are you managing bugs? How are you managing the development cycle? What priority is there on quality? If you can't measure it you can't manage it.
– Jane S♦
Jul 1 '15 at 3:03
Most of the bugs popped out at the end of the project. The senior engineer said it was due to bad code.
– Brainless
Jul 1 '15 at 3:13
2
Are you doing code reviews? Pair programming? Perhaps utilising a methodology like Agile may also help, if you are not already. Instead of a monolithic testing effort at the end, you can test after each iteration and push bugs back into the backlog to be addressed.
– Jane S♦
Jul 1 '15 at 3:15
2
Can you track when these bugs were introduced? That should give you an indication of the cause so you can try to plan around it. Don't be afraid to manage upwards (as early as possible) if the timeframes are too tight and introduces the risk of additional bugs!
– Jane S♦
Jul 1 '15 at 3:34
1
Note that the subject line really should be how to help them 's improve quality, especially if you're arguing it wasn't entirely their fault...
– keshlam
Jul 1 '15 at 4:36
 |Â
show 7 more comments
up vote
9
down vote
favorite
up vote
9
down vote
favorite
During our last project, our team composed of young software engineers made a product which contains much more bugs than other teams. We have a senior engineer who was part of the team, but isn't much involved in the development process as he has been promoted to manager. He just reviewed the team's code for the first time and found a lot of issues.
This team has shown strong capabilities in the past, but the result of our last project got me worried.
What the team members said about this last project:
- It is more complicated than our previous ones: lots of requirement change, complex interactions with the database, complex UI, new technologies...
- Not enough time, too much pressure
- Hard to understand the requirement (however we made sure everybody understands the requirements thoroughly during the project)
I trust my team, they are really good people. What can I do to make them improve their output?
project-management
asked Jul 1 '15 at 2:54
Brainless
180210
During our last project, our team composed of young software engineers made a product which contains much more bugs than other teams. We have a senior engineer who was part of the team, but isn't much involved in the development process as he has been promoted to manager. He just reviewed the team's code for the first time and found a lot of issues.
This team has shown strong capabilities in the past, but the result of our last project got me worried.
What the team members said about this last project:
- It is more complicated than our previous ones: lots of requirement change, complex interactions with the database, complex UI, new technologies...
- Not enough time, too much pressure
- Hard to understand the requirement (however we made sure everybody understands the requirements thoroughly during the project)
I trust my team, they are really good people. What can I do to make them improve their output?
project-management
asked Jul 1 '15 at 2:54
Brainless
180210
asked Jul 1 '15 at 2:54
Brainless
180210
asked Jul 1 '15 at 2:54
Brainless
180210
asked Jul 1 '15 at 2:54
Brainless
180210
180210
6
How are you managing bugs? How are you managing the development cycle? What priority is there on quality? If you can't measure it you can't manage it.
– Jane S♦
Jul 1 '15 at 3:03
Most of the bugs popped out at the end of the project. The senior engineer said it was due to bad code.
– Brainless
Jul 1 '15 at 3:13
2
Are you doing code reviews? Pair programming? Perhaps utilising a methodology like Agile may also help, if you are not already. Instead of a monolithic testing effort at the end, you can test after each iteration and push bugs back into the backlog to be addressed.
– Jane S♦
Jul 1 '15 at 3:15
2
Can you track when these bugs were introduced? That should give you an indication of the cause so you can try to plan around it. Don't be afraid to manage upwards (as early as possible) if the timeframes are too tight and introduces the risk of additional bugs!
– Jane S♦
Jul 1 '15 at 3:34
1
Note that the subject line really should be how to help them 's improve quality, especially if you're arguing it wasn't entirely their fault...
– keshlam
Jul 1 '15 at 4:36
 |Â
show 7 more comments
6
How are you managing bugs? How are you managing the development cycle? What priority is there on quality? If you can't measure it you can't manage it.
– Jane S♦
Jul 1 '15 at 3:03
Most of the bugs popped out at the end of the project. The senior engineer said it was due to bad code.
– Brainless
Jul 1 '15 at 3:13
2
Are you doing code reviews? Pair programming? Perhaps utilising a methodology like Agile may also help, if you are not already. Instead of a monolithic testing effort at the end, you can test after each iteration and push bugs back into the backlog to be addressed.
– Jane S♦
Jul 1 '15 at 3:15
2
Can you track when these bugs were introduced? That should give you an indication of the cause so you can try to plan around it. Don't be afraid to manage upwards (as early as possible) if the timeframes are too tight and introduces the risk of additional bugs!
– Jane S♦
Jul 1 '15 at 3:34
1
Note that the subject line really should be how to help them 's improve quality, especially if you're arguing it wasn't entirely their fault...
– keshlam
Jul 1 '15 at 4:36
6
6
How are you managing bugs? How are you managing the development cycle? What priority is there on quality? If you can't measure it you can't manage it.
– Jane S♦
Jul 1 '15 at 3:03
How are you managing bugs? How are you managing the development cycle? What priority is there on quality? If you can't measure it you can't manage it.
– Jane S♦
Jul 1 '15 at 3:03
Most of the bugs popped out at the end of the project. The senior engineer said it was due to bad code.
– Brainless
Jul 1 '15 at 3:13
Most of the bugs popped out at the end of the project. The senior engineer said it was due to bad code.
– Brainless
Jul 1 '15 at 3:13
2
2
Are you doing code reviews? Pair programming? Perhaps utilising a methodology like Agile may also help, if you are not already. Instead of a monolithic testing effort at the end, you can test after each iteration and push bugs back into the backlog to be addressed.
– Jane S♦
Jul 1 '15 at 3:15
Are you doing code reviews? Pair programming? Perhaps utilising a methodology like Agile may also help, if you are not already. Instead of a monolithic testing effort at the end, you can test after each iteration and push bugs back into the backlog to be addressed.
– Jane S♦
Jul 1 '15 at 3:15
2
2
Can you track when these bugs were introduced? That should give you an indication of the cause so you can try to plan around it. Don't be afraid to manage upwards (as early as possible) if the timeframes are too tight and introduces the risk of additional bugs!
– Jane S♦
Jul 1 '15 at 3:34
Can you track when these bugs were introduced? That should give you an indication of the cause so you can try to plan around it. Don't be afraid to manage upwards (as early as possible) if the timeframes are too tight and introduces the risk of additional bugs!
– Jane S♦
Jul 1 '15 at 3:34
1
1
Note that the subject line really should be how to help them 's improve quality, especially if you're arguing it wasn't entirely their fault...
– keshlam
Jul 1 '15 at 4:36
Note that the subject line really should be how to help them 's improve quality, especially if you're arguing it wasn't entirely their fault...
– keshlam
Jul 1 '15 at 4:36
 |Â
show 7 more comments
2 Answers
2
active
oldest
votes
up vote
14
down vote
accepted
To coalesce the comments into an answer, it seems as though the issue isn't specifically your team, but rather a management issue and having difficulty managing towards a tight deadline that led to rushing the final sprint. From the comments above:
We are using Agile. The team has been doing code reviews regularly (without the senior engineer). Their opinion about the code contradict the opinion of the senior engineer. For them, the code is ok. QA tested at each iteration, and as I said, it is only at the end that a lot of bugs appeared.
It sounds like you are doing the right things within the team. However:
I would rather believe that the last iteration was rushed. QA have done a great job in the past finding highly non trivial bugs. They got praised from other teams
It's easy to say that the problem revolves around that point, but looking deeper the issue is one of not necessarily managing the scope of each previous iteration to ensure the timeframe was realistic and not put undue pressure on the last sprint.
So how do you avoid this? Well, what you need to do is to track your progress against your delivery date. How many modules are left, and will it fit based on your current burndown rate and planned iterations? Do you have to make allowances for any bugs you've come across? If there is a discrepancy, raise it as early as possible so that you can either reduce scope or push out your deadline.
Your team seem to be doing the right things with regard to code quality. Where the issue seems to lie is in managing your sprint planning and tracking against your scope and delivery date.
answered Jul 1 '15 at 4:11
Jane S♦
40.8k17125159
2
Good answer. I would add that since the senior engineer (now manager) has found issues that the young team did not recognize, it would be prudent to involve the/a senior engineer in each of the iterations to review the code and mentor the younger ones. Hopefully the company organization would facilitate that type of involvement. Better code reviews will slow down the team velocity (for a time) but would pay off in the long run.
– Kent A.
Jul 1 '15 at 11:07
suggest improvements |Â
up vote
3
down vote
I would involve a senior person much earlier in code review in this case. We require code review before code can be pushed to QA. And then I would consider taking the code review advice and developng training from it if ther are consistent problems. But the single most critical piece in improving the qualit yof juniors is to not fix their code, but to make them fix it. They will learn more from doing the actual fixes once problems are identified. Make sure to explain why the items identified are problems instead of just flagging them.
answered Jul 1 '15 at 14:10
HLGEM
133k25226489
suggest improvements |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
14
down vote
accepted
To coalesce the comments into an answer, it seems as though the issue isn't specifically your team, but rather a management issue and having difficulty managing towards a tight deadline that led to rushing the final sprint. From the comments above:
We are using Agile. The team has been doing code reviews regularly (without the senior engineer). Their opinion about the code contradict the opinion of the senior engineer. For them, the code is ok. QA tested at each iteration, and as I said, it is only at the end that a lot of bugs appeared.
It sounds like you are doing the right things within the team. However:
I would rather believe that the last iteration was rushed. QA have done a great job in the past finding highly non trivial bugs. They got praised from other teams
It's easy to say that the problem revolves around that point, but looking deeper the issue is one of not necessarily managing the scope of each previous iteration to ensure the timeframe was realistic and not put undue pressure on the last sprint.
So how do you avoid this? Well, what you need to do is to track your progress against your delivery date. How many modules are left, and will it fit based on your current burndown rate and planned iterations? Do you have to make allowances for any bugs you've come across? If there is a discrepancy, raise it as early as possible so that you can either reduce scope or push out your deadline.
Your team seem to be doing the right things with regard to code quality. Where the issue seems to lie is in managing your sprint planning and tracking against your scope and delivery date.
answered Jul 1 '15 at 4:11
Jane S♦
40.8k17125159
2
Good answer. I would add that since the senior engineer (now manager) has found issues that the young team did not recognize, it would be prudent to involve the/a senior engineer in each of the iterations to review the code and mentor the younger ones. Hopefully the company organization would facilitate that type of involvement. Better code reviews will slow down the team velocity (for a time) but would pay off in the long run.
– Kent A.
Jul 1 '15 at 11:07
suggest improvements |Â
up vote
14
down vote
accepted
To coalesce the comments into an answer, it seems as though the issue isn't specifically your team, but rather a management issue and having difficulty managing towards a tight deadline that led to rushing the final sprint. From the comments above:
We are using Agile. The team has been doing code reviews regularly (without the senior engineer). Their opinion about the code contradict the opinion of the senior engineer. For them, the code is ok. QA tested at each iteration, and as I said, it is only at the end that a lot of bugs appeared.
It sounds like you are doing the right things within the team. However:
I would rather believe that the last iteration was rushed. QA have done a great job in the past finding highly non trivial bugs. They got praised from other teams
It's easy to say that the problem revolves around that point, but looking deeper the issue is one of not necessarily managing the scope of each previous iteration to ensure the timeframe was realistic and not put undue pressure on the last sprint.
So how do you avoid this? Well, what you need to do is to track your progress against your delivery date. How many modules are left, and will it fit based on your current burndown rate and planned iterations? Do you have to make allowances for any bugs you've come across? If there is a discrepancy, raise it as early as possible so that you can either reduce scope or push out your deadline.
Your team seem to be doing the right things with regard to code quality. Where the issue seems to lie is in managing your sprint planning and tracking against your scope and delivery date.
answered Jul 1 '15 at 4:11
Jane S♦
40.8k17125159
2
Good answer. I would add that since the senior engineer (now manager) has found issues that the young team did not recognize, it would be prudent to involve the/a senior engineer in each of the iterations to review the code and mentor the younger ones. Hopefully the company organization would facilitate that type of involvement. Better code reviews will slow down the team velocity (for a time) but would pay off in the long run.
– Kent A.
Jul 1 '15 at 11:07
suggest improvements |Â
up vote
14
down vote
accepted
up vote
14
down vote
accepted
To coalesce the comments into an answer, it seems as though the issue isn't specifically your team, but rather a management issue and having difficulty managing towards a tight deadline that led to rushing the final sprint. From the comments above:
We are using Agile. The team has been doing code reviews regularly (without the senior engineer). Their opinion about the code contradict the opinion of the senior engineer. For them, the code is ok. QA tested at each iteration, and as I said, it is only at the end that a lot of bugs appeared.
It sounds like you are doing the right things within the team. However:
I would rather believe that the last iteration was rushed. QA have done a great job in the past finding highly non trivial bugs. They got praised from other teams
It's easy to say that the problem revolves around that point, but looking deeper the issue is one of not necessarily managing the scope of each previous iteration to ensure the timeframe was realistic and not put undue pressure on the last sprint.
So how do you avoid this? Well, what you need to do is to track your progress against your delivery date. How many modules are left, and will it fit based on your current burndown rate and planned iterations? Do you have to make allowances for any bugs you've come across? If there is a discrepancy, raise it as early as possible so that you can either reduce scope or push out your deadline.
Your team seem to be doing the right things with regard to code quality. Where the issue seems to lie is in managing your sprint planning and tracking against your scope and delivery date.
answered Jul 1 '15 at 4:11
Jane S♦
40.8k17125159
To coalesce the comments into an answer, it seems as though the issue isn't specifically your team, but rather a management issue and having difficulty managing towards a tight deadline that led to rushing the final sprint. From the comments above:
We are using Agile. The team has been doing code reviews regularly (without the senior engineer). Their opinion about the code contradict the opinion of the senior engineer. For them, the code is ok. QA tested at each iteration, and as I said, it is only at the end that a lot of bugs appeared.
It sounds like you are doing the right things within the team. However:
I would rather believe that the last iteration was rushed. QA have done a great job in the past finding highly non trivial bugs. They got praised from other teams
It's easy to say that the problem revolves around that point, but looking deeper the issue is one of not necessarily managing the scope of each previous iteration to ensure the timeframe was realistic and not put undue pressure on the last sprint.
So how do you avoid this? Well, what you need to do is to track your progress against your delivery date. How many modules are left, and will it fit based on your current burndown rate and planned iterations? Do you have to make allowances for any bugs you've come across? If there is a discrepancy, raise it as early as possible so that you can either reduce scope or push out your deadline.
Your team seem to be doing the right things with regard to code quality. Where the issue seems to lie is in managing your sprint planning and tracking against your scope and delivery date.
answered Jul 1 '15 at 4:11
Jane S♦
40.8k17125159
answered Jul 1 '15 at 4:11
Jane S♦
40.8k17125159
answered Jul 1 '15 at 4:11
Jane S♦
40.8k17125159
answered Jul 1 '15 at 4:11
Jane S♦
40.8k17125159
40.8k17125159
2
Good answer. I would add that since the senior engineer (now manager) has found issues that the young team did not recognize, it would be prudent to involve the/a senior engineer in each of the iterations to review the code and mentor the younger ones. Hopefully the company organization would facilitate that type of involvement. Better code reviews will slow down the team velocity (for a time) but would pay off in the long run.
– Kent A.
Jul 1 '15 at 11:07
suggest improvements |Â
2
Good answer. I would add that since the senior engineer (now manager) has found issues that the young team did not recognize, it would be prudent to involve the/a senior engineer in each of the iterations to review the code and mentor the younger ones. Hopefully the company organization would facilitate that type of involvement. Better code reviews will slow down the team velocity (for a time) but would pay off in the long run.
– Kent A.
Jul 1 '15 at 11:07
2
2
Good answer. I would add that since the senior engineer (now manager) has found issues that the young team did not recognize, it would be prudent to involve the/a senior engineer in each of the iterations to review the code and mentor the younger ones. Hopefully the company organization would facilitate that type of involvement. Better code reviews will slow down the team velocity (for a time) but would pay off in the long run.
– Kent A.
Jul 1 '15 at 11:07
Good answer. I would add that since the senior engineer (now manager) has found issues that the young team did not recognize, it would be prudent to involve the/a senior engineer in each of the iterations to review the code and mentor the younger ones. Hopefully the company organization would facilitate that type of involvement. Better code reviews will slow down the team velocity (for a time) but would pay off in the long run.
– Kent A.
Jul 1 '15 at 11:07
suggest improvements |Â
up vote
3
down vote
I would involve a senior person much earlier in code review in this case. We require code review before code can be pushed to QA. And then I would consider taking the code review advice and developng training from it if ther are consistent problems. But the single most critical piece in improving the qualit yof juniors is to not fix their code, but to make them fix it. They will learn more from doing the actual fixes once problems are identified. Make sure to explain why the items identified are problems instead of just flagging them.
answered Jul 1 '15 at 14:10
HLGEM
133k25226489
suggest improvements |Â
up vote
3
down vote
I would involve a senior person much earlier in code review in this case. We require code review before code can be pushed to QA. And then I would consider taking the code review advice and developng training from it if ther are consistent problems. But the single most critical piece in improving the qualit yof juniors is to not fix their code, but to make them fix it. They will learn more from doing the actual fixes once problems are identified. Make sure to explain why the items identified are problems instead of just flagging them.
answered Jul 1 '15 at 14:10
HLGEM
133k25226489
suggest improvements |Â
up vote
3
down vote
up vote
3
down vote
I would involve a senior person much earlier in code review in this case. We require code review before code can be pushed to QA. And then I would consider taking the code review advice and developng training from it if ther are consistent problems. But the single most critical piece in improving the qualit yof juniors is to not fix their code, but to make them fix it. They will learn more from doing the actual fixes once problems are identified. Make sure to explain why the items identified are problems instead of just flagging them.
answered Jul 1 '15 at 14:10
HLGEM
133k25226489
I would involve a senior person much earlier in code review in this case. We require code review before code can be pushed to QA. And then I would consider taking the code review advice and developng training from it if ther are consistent problems. But the single most critical piece in improving the qualit yof juniors is to not fix their code, but to make them fix it. They will learn more from doing the actual fixes once problems are identified. Make sure to explain why the items identified are problems instead of just flagging them.
answered Jul 1 '15 at 14:10
HLGEM
133k25226489
answered Jul 1 '15 at 14:10
HLGEM
133k25226489
answered Jul 1 '15 at 14:10
HLGEM
133k25226489
answered Jul 1 '15 at 14:10
HLGEM
133k25226489
133k25226489
suggest improvements |Â
suggest improvements |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f49050%2fhow-to-make-young-software-engineers-improve-the-quality-of-their-output%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
6
How are you managing bugs? How are you managing the development cycle? What priority is there on quality? If you can't measure it you can't manage it.
– Jane S♦
Jul 1 '15 at 3:03
Most of the bugs popped out at the end of the project. The senior engineer said it was due to bad code.
– Brainless
Jul 1 '15 at 3:13
2
Are you doing code reviews? Pair programming? Perhaps utilising a methodology like Agile may also help, if you are not already. Instead of a monolithic testing effort at the end, you can test after each iteration and push bugs back into the backlog to be addressed.
– Jane S♦
Jul 1 '15 at 3:15
2
Can you track when these bugs were introduced? That should give you an indication of the cause so you can try to plan around it. Don't be afraid to manage upwards (as early as possible) if the timeframes are too tight and introduces the risk of additional bugs!
– Jane S♦
Jul 1 '15 at 3:34
1
Note that the subject line really should be how to help them 's improve quality, especially if you're arguing it wasn't entirely their fault...
– keshlam
Jul 1 '15 at 4:36