Mixing
Is there a polite way to say that a colleague is too relaxed with the “Definition of Done�
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
5
down vote
favorite
I'd like to ask you, how do I handle a situation where a colleague declares a functionality of our project to be "done" to our superior when it still has room for improvement, and (programming term incoming) refactoring needs to be done.
This seems like a problem with the Definition of Done
Furthermore I can't find any guidelines for that, firm-wise.
We have to do fixes a few months after the project has been declared done, and that would involve more effort if especially this review and refactoring is omitted.
And, to add to this, I have the feeling that he gets insulted when I say that I'd like to review something before he declares it "done", and he almost has as much experience as I do, and has been in the firm a little bit more than I.
I'm frustrated, because the depth of the work is affected just as in this question.
professionalism software-industry colleagues
edited Apr 13 '17 at 12:48
Community♦
1
asked Apr 10 '14 at 8:51
Hard Worker
306214
add a comment |Â
up vote
5
down vote
favorite
I'd like to ask you, how do I handle a situation where a colleague declares a functionality of our project to be "done" to our superior when it still has room for improvement, and (programming term incoming) refactoring needs to be done.
This seems like a problem with the Definition of Done
Furthermore I can't find any guidelines for that, firm-wise.
We have to do fixes a few months after the project has been declared done, and that would involve more effort if especially this review and refactoring is omitted.
And, to add to this, I have the feeling that he gets insulted when I say that I'd like to review something before he declares it "done", and he almost has as much experience as I do, and has been in the firm a little bit more than I.
I'm frustrated, because the depth of the work is affected just as in this question.
professionalism software-industry colleagues
edited Apr 13 '17 at 12:48
Community♦
1
asked Apr 10 '14 at 8:51
Hard Worker
306214
4
My office had problems similar to this in the past. It took a huge team oriented movement to get past this problem. We had several meeting through the span of several weeks arguing over what the definition of done for any given task should be. The result was we had well defined definition of done. The way you reach that with your team will be unique, but you cannot single one person out, it has to be a team effort. Take into account testing, refactoring, requirements...etc.BestApproachIsMakeTheTeamAwareOf the TEAM problem, andtryto mention the importance, From there a manager should handle it.
– TheOneWhoPrograms
Apr 10 '14 at 8:59
2
If I were the superior, I'd definitely throw the ball back at your colleague. Having said that, my definition of "done" may be limited to doing the absolute minimum to get it declared as "done". If the program does what the specs say, then it meets the minimum definition of "done" This is not to say that meeting the minimum definition of "done" is optimal for the task, the project or the firm. Far from it. The superior will have to decide what is meant by "done", set policy on it and ultimately sign off on the tasks and projects as "done", taking into account any disagreements.
– Vietnhi Phuvan
Apr 10 '14 at 10:24
3
Strictly speaking, refactoring has no impact upon observable behavior. So "refactoring needs to be done" is not an indication that a task is not done yet. Unless that task was "refactor the code". If the functional requirements are met, then the task will likely be considered "done". The amount of refactoring needed is a reflection of accrued technical debt more than it is a modifier on the level of "doneness" of the task.
– aroth
Apr 10 '14 at 13:14
What software is ever really done? Software may be abandoned, rarely does it ever get to the point of perfection.
– JB King
Apr 10 '14 at 20:34
add a comment |Â
up vote
5
down vote
favorite
up vote
5
down vote
favorite
I'd like to ask you, how do I handle a situation where a colleague declares a functionality of our project to be "done" to our superior when it still has room for improvement, and (programming term incoming) refactoring needs to be done.
This seems like a problem with the Definition of Done
Furthermore I can't find any guidelines for that, firm-wise.
We have to do fixes a few months after the project has been declared done, and that would involve more effort if especially this review and refactoring is omitted.
And, to add to this, I have the feeling that he gets insulted when I say that I'd like to review something before he declares it "done", and he almost has as much experience as I do, and has been in the firm a little bit more than I.
I'm frustrated, because the depth of the work is affected just as in this question.
professionalism software-industry colleagues
edited Apr 13 '17 at 12:48
Community♦
1
asked Apr 10 '14 at 8:51
Hard Worker
306214
I'd like to ask you, how do I handle a situation where a colleague declares a functionality of our project to be "done" to our superior when it still has room for improvement, and (programming term incoming) refactoring needs to be done.
This seems like a problem with the Definition of Done
Furthermore I can't find any guidelines for that, firm-wise.
We have to do fixes a few months after the project has been declared done, and that would involve more effort if especially this review and refactoring is omitted.
And, to add to this, I have the feeling that he gets insulted when I say that I'd like to review something before he declares it "done", and he almost has as much experience as I do, and has been in the firm a little bit more than I.
I'm frustrated, because the depth of the work is affected just as in this question.
professionalism software-industry colleagues
edited Apr 13 '17 at 12:48
Community♦
1
asked Apr 10 '14 at 8:51
Hard Worker
306214
edited Apr 13 '17 at 12:48
Community♦
1
edited Apr 13 '17 at 12:48
Community♦
1
edited Apr 13 '17 at 12:48
Community♦
1
1
asked Apr 10 '14 at 8:51
Hard Worker
306214
asked Apr 10 '14 at 8:51
Hard Worker
306214
asked Apr 10 '14 at 8:51
Hard Worker
306214
306214
4
My office had problems similar to this in the past. It took a huge team oriented movement to get past this problem. We had several meeting through the span of several weeks arguing over what the definition of done for any given task should be. The result was we had well defined definition of done. The way you reach that with your team will be unique, but you cannot single one person out, it has to be a team effort. Take into account testing, refactoring, requirements...etc.BestApproachIsMakeTheTeamAwareOf the TEAM problem, andtryto mention the importance, From there a manager should handle it.
– TheOneWhoPrograms
Apr 10 '14 at 8:59
2
If I were the superior, I'd definitely throw the ball back at your colleague. Having said that, my definition of "done" may be limited to doing the absolute minimum to get it declared as "done". If the program does what the specs say, then it meets the minimum definition of "done" This is not to say that meeting the minimum definition of "done" is optimal for the task, the project or the firm. Far from it. The superior will have to decide what is meant by "done", set policy on it and ultimately sign off on the tasks and projects as "done", taking into account any disagreements.
– Vietnhi Phuvan
Apr 10 '14 at 10:24
3
Strictly speaking, refactoring has no impact upon observable behavior. So "refactoring needs to be done" is not an indication that a task is not done yet. Unless that task was "refactor the code". If the functional requirements are met, then the task will likely be considered "done". The amount of refactoring needed is a reflection of accrued technical debt more than it is a modifier on the level of "doneness" of the task.
– aroth
Apr 10 '14 at 13:14
What software is ever really done? Software may be abandoned, rarely does it ever get to the point of perfection.
– JB King
Apr 10 '14 at 20:34
add a comment |Â
4
My office had problems similar to this in the past. It took a huge team oriented movement to get past this problem. We had several meeting through the span of several weeks arguing over what the definition of done for any given task should be. The result was we had well defined definition of done. The way you reach that with your team will be unique, but you cannot single one person out, it has to be a team effort. Take into account testing, refactoring, requirements...etc.BestApproachIsMakeTheTeamAwareOf the TEAM problem, andtryto mention the importance, From there a manager should handle it.
– TheOneWhoPrograms
Apr 10 '14 at 8:59
2
If I were the superior, I'd definitely throw the ball back at your colleague. Having said that, my definition of "done" may be limited to doing the absolute minimum to get it declared as "done". If the program does what the specs say, then it meets the minimum definition of "done" This is not to say that meeting the minimum definition of "done" is optimal for the task, the project or the firm. Far from it. The superior will have to decide what is meant by "done", set policy on it and ultimately sign off on the tasks and projects as "done", taking into account any disagreements.
– Vietnhi Phuvan
Apr 10 '14 at 10:24
3
Strictly speaking, refactoring has no impact upon observable behavior. So "refactoring needs to be done" is not an indication that a task is not done yet. Unless that task was "refactor the code". If the functional requirements are met, then the task will likely be considered "done". The amount of refactoring needed is a reflection of accrued technical debt more than it is a modifier on the level of "doneness" of the task.
– aroth
Apr 10 '14 at 13:14
What software is ever really done? Software may be abandoned, rarely does it ever get to the point of perfection.
– JB King
Apr 10 '14 at 20:34
4
4
My office had problems similar to this in the past. It took a huge team oriented movement to get past this problem. We had several meeting through the span of several weeks arguing over what the definition of done for any given task should be. The result was we had well defined definition of done. The way you reach that with your team will be unique, but you cannot single one person out, it has to be a team effort. Take into account testing, refactoring, requirements...etc.BestApproachIsMakeTheTeamAwareOf the TEAM problem, andtryto mention the importance, From there a manager should handle it.
– TheOneWhoPrograms
Apr 10 '14 at 8:59
My office had problems similar to this in the past. It took a huge team oriented movement to get past this problem. We had several meeting through the span of several weeks arguing over what the definition of done for any given task should be. The result was we had well defined definition of done. The way you reach that with your team will be unique, but you cannot single one person out, it has to be a team effort. Take into account testing, refactoring, requirements...etc.BestApproachIsMakeTheTeamAwareOf the TEAM problem, andtryto mention the importance, From there a manager should handle it.
– TheOneWhoPrograms
Apr 10 '14 at 8:59
2
2
If I were the superior, I'd definitely throw the ball back at your colleague. Having said that, my definition of "done" may be limited to doing the absolute minimum to get it declared as "done". If the program does what the specs say, then it meets the minimum definition of "done" This is not to say that meeting the minimum definition of "done" is optimal for the task, the project or the firm. Far from it. The superior will have to decide what is meant by "done", set policy on it and ultimately sign off on the tasks and projects as "done", taking into account any disagreements.
– Vietnhi Phuvan
Apr 10 '14 at 10:24
If I were the superior, I'd definitely throw the ball back at your colleague. Having said that, my definition of "done" may be limited to doing the absolute minimum to get it declared as "done". If the program does what the specs say, then it meets the minimum definition of "done" This is not to say that meeting the minimum definition of "done" is optimal for the task, the project or the firm. Far from it. The superior will have to decide what is meant by "done", set policy on it and ultimately sign off on the tasks and projects as "done", taking into account any disagreements.
– Vietnhi Phuvan
Apr 10 '14 at 10:24
3
3
Strictly speaking, refactoring has no impact upon observable behavior. So "refactoring needs to be done" is not an indication that a task is not done yet. Unless that task was "refactor the code". If the functional requirements are met, then the task will likely be considered "done". The amount of refactoring needed is a reflection of accrued technical debt more than it is a modifier on the level of "doneness" of the task.
– aroth
Apr 10 '14 at 13:14
Strictly speaking, refactoring has no impact upon observable behavior. So "refactoring needs to be done" is not an indication that a task is not done yet. Unless that task was "refactor the code". If the functional requirements are met, then the task will likely be considered "done". The amount of refactoring needed is a reflection of accrued technical debt more than it is a modifier on the level of "doneness" of the task.
– aroth
Apr 10 '14 at 13:14
What software is ever really done? Software may be abandoned, rarely does it ever get to the point of perfection.
– JB King
Apr 10 '14 at 20:34
What software is ever really done? Software may be abandoned, rarely does it ever get to the point of perfection.
– JB King
Apr 10 '14 at 20:34
add a comment |Â
3 Answers
3
active
oldest
votes
up vote
10
down vote
accepted
Furthermore I can't find any guidelines for that, firm-wise.
That seems like the best place to start. Instead of treating this as an issue with one specific colleague and the way he does his work, approach it as an organizational issue (or at least, as a team-wide issue). Because that's what it is.
If the only things your colleague is omitting are things that do not impact upon the observable behavior of the code, then you really don't have a leg to stand on when you say things aren't done if there's no company-/team-wide policy that says "development work is not done unless...".
So I'd suggest you broach this topic to a project manager/team lead and approach it as a general process and quality improvement rather than a gripe about one person's behavior. Propose a definition of "done" that covers what you feel are the important points, and see if you can get buy-in (from other developers and management as well). Some things to include might be:
- Development work is not done unless the project compiles/builds successfully.
- Development work is not done unless all code has been peer-reviewed.
- Development work is not done unless every new line of code is covered by a unit-test.
- Development work is not done unless all new functionality is covered by integration tests.
- Development work is not done if there are any failing tests.
- Development work is not done unless all style guidelines and development best-practices have been adhered to.
- Development work is not done if the code still smells.
If you can't get buy-in for your definition of "done" then you may have to look at whether the organization is the right place for you, from a cultural perspective. Perhaps the only "done" the firm cares about is of the "observable functionality" variety, in which case your colleague is technically correct in calling his work done.
Which isn't to say that I think it's okay for an organization to not make code quality a top priority. But the fact of the matter is many of them do not.
In any case, if you approach it as an organizational/team issue, you remove any direct friction between yourself and your colleague. If the whole development team gets behind a consistent standard of "done" that includes the things you're most concerned about then your colleague has no reason to feel put upon or singled out by the requirements. Everyone is held to the same standards.
answered Apr 10 '14 at 13:44
aroth
8,29812646
add a comment |Â
up vote
5
down vote
A piece of functionality is "done" when the client — whether this is an actual paying customer, your supervisor or another internal user within the organisation — accepts it as such. There is no objective definition, and it would almost certainly be impossible to come up with one that was practically useful (in particular, if you define "done" as "perfect, with no room for improvement" then nothing will ever be done).
In most cases the client's view of what is "done" will be based on the observable functionality: does it work according to their requirements and behave as they expect without exhibiting bugs that interrupt their workflow. They have no reason to care about the structure of the code, and are unlikely to be willing to pay for additional development time just to cover internal refactoring that doesn't result in any user-visible improvements. With this in mind, your colleague's "definition of done" is probably reasonable, and you may have difficulty convincing your supervisor otherwise.
Of course, as developers we all know that the internal design of software is important, and the time to bring this up is during estimates for future work. If the code structure is poor, then future changes will be more difficult and take longer, and the need for preliminary refactoring should be included in your estimates. If the client complains that changes are consistently taking too long, you then have a solid basis on which to raise the issue of coding quality and best practices within your team.
2
I'm not sure I agree. There is not one-size-fits-all/universal definition of "done". However many organizations will indeed set an objective standard by which a task may be considered done. For instance, it's not uncommon to declare that a task cannot be considered done unless there are unit or integration tests (or both) to cover the new code. Or that no task is done until a second developer has reviewed the code. And so on. It doesn't always come down to just observable functionality. Especially for things like in-house development projects.
– aroth
Apr 10 '14 at 13:21
@aroth - Not that it is a single definition, but the client or even in-house user's satisfaction is the bottom line. What good is a passing test for a piece of functionality that does not do what the client wants?
– user8365
Apr 10 '14 at 16:55
@JeffO Having the test wouldn't excuse the functionality if it's not to spec. The implicit minimum standard is that a task isn't done unless it satisfies its functional requirements. Additional requirements, like testing, are applied on top of that. So client satisfaction is very important, in a "necessary but not (always) sufficient" kind of way.
– aroth
Apr 11 '14 at 0:02
add a comment |Â
up vote
2
down vote
Depending on the size of your company and where you fit in the heirarchy, it sounds like a cultural change could be in order.
I work for a large corporation, and before any significant milestone, particularly completion of a project, we are required to go through a formal peer review process. The person responsible for the work goes over it with a few technically knowledgable people - presumably including you and your boss - and everyone offers comments and suggestions of what needs to be fixed before this step can be declared complete. It would be easier to get your point across to your colleague with other people to back you up, or maybe you'll discover that you're the only person who thinks these changes are necessary. You should leave the meeting with a specific list of changes that need to be addressed to declare completion.
Adding these types of meetings are something that would need to be done across the board - not just when you think someone isn't doing their job. This means that your work should be subject to comments from others as well! If you're not in a situation to do this company-wide, then talk to your boss about getting this set up for your team. If this results in better products coming out of your group, the higher ups are bound to take notice and may even implement it in other divisions.
answered Apr 10 '14 at 13:15
David K
20.8k1075110
add a comment |Â
StackExchange.ready(function ()
$("#show-editor-button input, #show-editor-button button").click(function ()
var showEditor = function()
$("#show-editor-button").hide();
$("#post-form").removeClass("dno");
StackExchange.editor.finallyInit();
;
var useFancy = $(this).data('confirm-use-fancy');
if(useFancy == 'True')
var popupTitle = $(this).data('confirm-fancy-title');
var popupBody = $(this).data('confirm-fancy-body');
var popupAccept = $(this).data('confirm-fancy-accept-button');
$(this).loadPopup(
url: '/post/self-answer-popup',
loaded: function(popup)
var pTitle = $(popup).find('h2');
var pBody = $(popup).find('.popup-body');
var pSubmit = $(popup).find('.popup-submit');
pTitle.text(popupTitle);
pBody.html(popupBody);
pSubmit.val(popupAccept).click(showEditor);
)
else
var confirmText = $(this).data('confirm-text');
if (confirmText ? confirm(confirmText) : true)
showEditor();
);
);
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
10
down vote
accepted
Furthermore I can't find any guidelines for that, firm-wise.
That seems like the best place to start. Instead of treating this as an issue with one specific colleague and the way he does his work, approach it as an organizational issue (or at least, as a team-wide issue). Because that's what it is.
If the only things your colleague is omitting are things that do not impact upon the observable behavior of the code, then you really don't have a leg to stand on when you say things aren't done if there's no company-/team-wide policy that says "development work is not done unless...".
So I'd suggest you broach this topic to a project manager/team lead and approach it as a general process and quality improvement rather than a gripe about one person's behavior. Propose a definition of "done" that covers what you feel are the important points, and see if you can get buy-in (from other developers and management as well). Some things to include might be:
- Development work is not done unless the project compiles/builds successfully.
- Development work is not done unless all code has been peer-reviewed.
- Development work is not done unless every new line of code is covered by a unit-test.
- Development work is not done unless all new functionality is covered by integration tests.
- Development work is not done if there are any failing tests.
- Development work is not done unless all style guidelines and development best-practices have been adhered to.
- Development work is not done if the code still smells.
If you can't get buy-in for your definition of "done" then you may have to look at whether the organization is the right place for you, from a cultural perspective. Perhaps the only "done" the firm cares about is of the "observable functionality" variety, in which case your colleague is technically correct in calling his work done.
Which isn't to say that I think it's okay for an organization to not make code quality a top priority. But the fact of the matter is many of them do not.
In any case, if you approach it as an organizational/team issue, you remove any direct friction between yourself and your colleague. If the whole development team gets behind a consistent standard of "done" that includes the things you're most concerned about then your colleague has no reason to feel put upon or singled out by the requirements. Everyone is held to the same standards.
answered Apr 10 '14 at 13:44
aroth
8,29812646
add a comment |Â
up vote
10
down vote
accepted
Furthermore I can't find any guidelines for that, firm-wise.
That seems like the best place to start. Instead of treating this as an issue with one specific colleague and the way he does his work, approach it as an organizational issue (or at least, as a team-wide issue). Because that's what it is.
If the only things your colleague is omitting are things that do not impact upon the observable behavior of the code, then you really don't have a leg to stand on when you say things aren't done if there's no company-/team-wide policy that says "development work is not done unless...".
So I'd suggest you broach this topic to a project manager/team lead and approach it as a general process and quality improvement rather than a gripe about one person's behavior. Propose a definition of "done" that covers what you feel are the important points, and see if you can get buy-in (from other developers and management as well). Some things to include might be:
- Development work is not done unless the project compiles/builds successfully.
- Development work is not done unless all code has been peer-reviewed.
- Development work is not done unless every new line of code is covered by a unit-test.
- Development work is not done unless all new functionality is covered by integration tests.
- Development work is not done if there are any failing tests.
- Development work is not done unless all style guidelines and development best-practices have been adhered to.
- Development work is not done if the code still smells.
If you can't get buy-in for your definition of "done" then you may have to look at whether the organization is the right place for you, from a cultural perspective. Perhaps the only "done" the firm cares about is of the "observable functionality" variety, in which case your colleague is technically correct in calling his work done.
Which isn't to say that I think it's okay for an organization to not make code quality a top priority. But the fact of the matter is many of them do not.
In any case, if you approach it as an organizational/team issue, you remove any direct friction between yourself and your colleague. If the whole development team gets behind a consistent standard of "done" that includes the things you're most concerned about then your colleague has no reason to feel put upon or singled out by the requirements. Everyone is held to the same standards.
answered Apr 10 '14 at 13:44
aroth
8,29812646
add a comment |Â
up vote
10
down vote
accepted
up vote
10
down vote
accepted
Furthermore I can't find any guidelines for that, firm-wise.
That seems like the best place to start. Instead of treating this as an issue with one specific colleague and the way he does his work, approach it as an organizational issue (or at least, as a team-wide issue). Because that's what it is.
If the only things your colleague is omitting are things that do not impact upon the observable behavior of the code, then you really don't have a leg to stand on when you say things aren't done if there's no company-/team-wide policy that says "development work is not done unless...".
So I'd suggest you broach this topic to a project manager/team lead and approach it as a general process and quality improvement rather than a gripe about one person's behavior. Propose a definition of "done" that covers what you feel are the important points, and see if you can get buy-in (from other developers and management as well). Some things to include might be:
- Development work is not done unless the project compiles/builds successfully.
- Development work is not done unless all code has been peer-reviewed.
- Development work is not done unless every new line of code is covered by a unit-test.
- Development work is not done unless all new functionality is covered by integration tests.
- Development work is not done if there are any failing tests.
- Development work is not done unless all style guidelines and development best-practices have been adhered to.
- Development work is not done if the code still smells.
If you can't get buy-in for your definition of "done" then you may have to look at whether the organization is the right place for you, from a cultural perspective. Perhaps the only "done" the firm cares about is of the "observable functionality" variety, in which case your colleague is technically correct in calling his work done.
Which isn't to say that I think it's okay for an organization to not make code quality a top priority. But the fact of the matter is many of them do not.
In any case, if you approach it as an organizational/team issue, you remove any direct friction between yourself and your colleague. If the whole development team gets behind a consistent standard of "done" that includes the things you're most concerned about then your colleague has no reason to feel put upon or singled out by the requirements. Everyone is held to the same standards.
answered Apr 10 '14 at 13:44
aroth
8,29812646
Furthermore I can't find any guidelines for that, firm-wise.
That seems like the best place to start. Instead of treating this as an issue with one specific colleague and the way he does his work, approach it as an organizational issue (or at least, as a team-wide issue). Because that's what it is.
If the only things your colleague is omitting are things that do not impact upon the observable behavior of the code, then you really don't have a leg to stand on when you say things aren't done if there's no company-/team-wide policy that says "development work is not done unless...".
So I'd suggest you broach this topic to a project manager/team lead and approach it as a general process and quality improvement rather than a gripe about one person's behavior. Propose a definition of "done" that covers what you feel are the important points, and see if you can get buy-in (from other developers and management as well). Some things to include might be:
- Development work is not done unless the project compiles/builds successfully.
- Development work is not done unless all code has been peer-reviewed.
- Development work is not done unless every new line of code is covered by a unit-test.
- Development work is not done unless all new functionality is covered by integration tests.
- Development work is not done if there are any failing tests.
- Development work is not done unless all style guidelines and development best-practices have been adhered to.
- Development work is not done if the code still smells.
If you can't get buy-in for your definition of "done" then you may have to look at whether the organization is the right place for you, from a cultural perspective. Perhaps the only "done" the firm cares about is of the "observable functionality" variety, in which case your colleague is technically correct in calling his work done.
Which isn't to say that I think it's okay for an organization to not make code quality a top priority. But the fact of the matter is many of them do not.
In any case, if you approach it as an organizational/team issue, you remove any direct friction between yourself and your colleague. If the whole development team gets behind a consistent standard of "done" that includes the things you're most concerned about then your colleague has no reason to feel put upon or singled out by the requirements. Everyone is held to the same standards.
answered Apr 10 '14 at 13:44
aroth
8,29812646
edited Apr 10 '14 at 14:06
answered Apr 10 '14 at 13:44
aroth
8,29812646
answered Apr 10 '14 at 13:44
aroth
8,29812646
answered Apr 10 '14 at 13:44
aroth
8,29812646
8,29812646
add a comment |Â
add a comment |Â
up vote
5
down vote
A piece of functionality is "done" when the client — whether this is an actual paying customer, your supervisor or another internal user within the organisation — accepts it as such. There is no objective definition, and it would almost certainly be impossible to come up with one that was practically useful (in particular, if you define "done" as "perfect, with no room for improvement" then nothing will ever be done).
In most cases the client's view of what is "done" will be based on the observable functionality: does it work according to their requirements and behave as they expect without exhibiting bugs that interrupt their workflow. They have no reason to care about the structure of the code, and are unlikely to be willing to pay for additional development time just to cover internal refactoring that doesn't result in any user-visible improvements. With this in mind, your colleague's "definition of done" is probably reasonable, and you may have difficulty convincing your supervisor otherwise.
Of course, as developers we all know that the internal design of software is important, and the time to bring this up is during estimates for future work. If the code structure is poor, then future changes will be more difficult and take longer, and the need for preliminary refactoring should be included in your estimates. If the client complains that changes are consistently taking too long, you then have a solid basis on which to raise the issue of coding quality and best practices within your team.
2
I'm not sure I agree. There is not one-size-fits-all/universal definition of "done". However many organizations will indeed set an objective standard by which a task may be considered done. For instance, it's not uncommon to declare that a task cannot be considered done unless there are unit or integration tests (or both) to cover the new code. Or that no task is done until a second developer has reviewed the code. And so on. It doesn't always come down to just observable functionality. Especially for things like in-house development projects.
– aroth
Apr 10 '14 at 13:21
@aroth - Not that it is a single definition, but the client or even in-house user's satisfaction is the bottom line. What good is a passing test for a piece of functionality that does not do what the client wants?
– user8365
Apr 10 '14 at 16:55
@JeffO Having the test wouldn't excuse the functionality if it's not to spec. The implicit minimum standard is that a task isn't done unless it satisfies its functional requirements. Additional requirements, like testing, are applied on top of that. So client satisfaction is very important, in a "necessary but not (always) sufficient" kind of way.
– aroth
Apr 11 '14 at 0:02
add a comment |Â
up vote
5
down vote
A piece of functionality is "done" when the client — whether this is an actual paying customer, your supervisor or another internal user within the organisation — accepts it as such. There is no objective definition, and it would almost certainly be impossible to come up with one that was practically useful (in particular, if you define "done" as "perfect, with no room for improvement" then nothing will ever be done).
In most cases the client's view of what is "done" will be based on the observable functionality: does it work according to their requirements and behave as they expect without exhibiting bugs that interrupt their workflow. They have no reason to care about the structure of the code, and are unlikely to be willing to pay for additional development time just to cover internal refactoring that doesn't result in any user-visible improvements. With this in mind, your colleague's "definition of done" is probably reasonable, and you may have difficulty convincing your supervisor otherwise.
Of course, as developers we all know that the internal design of software is important, and the time to bring this up is during estimates for future work. If the code structure is poor, then future changes will be more difficult and take longer, and the need for preliminary refactoring should be included in your estimates. If the client complains that changes are consistently taking too long, you then have a solid basis on which to raise the issue of coding quality and best practices within your team.
2
I'm not sure I agree. There is not one-size-fits-all/universal definition of "done". However many organizations will indeed set an objective standard by which a task may be considered done. For instance, it's not uncommon to declare that a task cannot be considered done unless there are unit or integration tests (or both) to cover the new code. Or that no task is done until a second developer has reviewed the code. And so on. It doesn't always come down to just observable functionality. Especially for things like in-house development projects.
– aroth
Apr 10 '14 at 13:21
@aroth - Not that it is a single definition, but the client or even in-house user's satisfaction is the bottom line. What good is a passing test for a piece of functionality that does not do what the client wants?
– user8365
Apr 10 '14 at 16:55
@JeffO Having the test wouldn't excuse the functionality if it's not to spec. The implicit minimum standard is that a task isn't done unless it satisfies its functional requirements. Additional requirements, like testing, are applied on top of that. So client satisfaction is very important, in a "necessary but not (always) sufficient" kind of way.
– aroth
Apr 11 '14 at 0:02
add a comment |Â
up vote
5
down vote
up vote
5
down vote
A piece of functionality is "done" when the client — whether this is an actual paying customer, your supervisor or another internal user within the organisation — accepts it as such. There is no objective definition, and it would almost certainly be impossible to come up with one that was practically useful (in particular, if you define "done" as "perfect, with no room for improvement" then nothing will ever be done).
In most cases the client's view of what is "done" will be based on the observable functionality: does it work according to their requirements and behave as they expect without exhibiting bugs that interrupt their workflow. They have no reason to care about the structure of the code, and are unlikely to be willing to pay for additional development time just to cover internal refactoring that doesn't result in any user-visible improvements. With this in mind, your colleague's "definition of done" is probably reasonable, and you may have difficulty convincing your supervisor otherwise.
Of course, as developers we all know that the internal design of software is important, and the time to bring this up is during estimates for future work. If the code structure is poor, then future changes will be more difficult and take longer, and the need for preliminary refactoring should be included in your estimates. If the client complains that changes are consistently taking too long, you then have a solid basis on which to raise the issue of coding quality and best practices within your team.
A piece of functionality is "done" when the client — whether this is an actual paying customer, your supervisor or another internal user within the organisation — accepts it as such. There is no objective definition, and it would almost certainly be impossible to come up with one that was practically useful (in particular, if you define "done" as "perfect, with no room for improvement" then nothing will ever be done).
In most cases the client's view of what is "done" will be based on the observable functionality: does it work according to their requirements and behave as they expect without exhibiting bugs that interrupt their workflow. They have no reason to care about the structure of the code, and are unlikely to be willing to pay for additional development time just to cover internal refactoring that doesn't result in any user-visible improvements. With this in mind, your colleague's "definition of done" is probably reasonable, and you may have difficulty convincing your supervisor otherwise.
Of course, as developers we all know that the internal design of software is important, and the time to bring this up is during estimates for future work. If the code structure is poor, then future changes will be more difficult and take longer, and the need for preliminary refactoring should be included in your estimates. If the client complains that changes are consistently taking too long, you then have a solid basis on which to raise the issue of coding quality and best practices within your team.
answered Apr 10 '14 at 11:07
user7444
2
I'm not sure I agree. There is not one-size-fits-all/universal definition of "done". However many organizations will indeed set an objective standard by which a task may be considered done. For instance, it's not uncommon to declare that a task cannot be considered done unless there are unit or integration tests (or both) to cover the new code. Or that no task is done until a second developer has reviewed the code. And so on. It doesn't always come down to just observable functionality. Especially for things like in-house development projects.
– aroth
Apr 10 '14 at 13:21
@aroth - Not that it is a single definition, but the client or even in-house user's satisfaction is the bottom line. What good is a passing test for a piece of functionality that does not do what the client wants?
– user8365
Apr 10 '14 at 16:55
@JeffO Having the test wouldn't excuse the functionality if it's not to spec. The implicit minimum standard is that a task isn't done unless it satisfies its functional requirements. Additional requirements, like testing, are applied on top of that. So client satisfaction is very important, in a "necessary but not (always) sufficient" kind of way.
– aroth
Apr 11 '14 at 0:02
add a comment |Â
2
I'm not sure I agree. There is not one-size-fits-all/universal definition of "done". However many organizations will indeed set an objective standard by which a task may be considered done. For instance, it's not uncommon to declare that a task cannot be considered done unless there are unit or integration tests (or both) to cover the new code. Or that no task is done until a second developer has reviewed the code. And so on. It doesn't always come down to just observable functionality. Especially for things like in-house development projects.
– aroth
Apr 10 '14 at 13:21
@aroth - Not that it is a single definition, but the client or even in-house user's satisfaction is the bottom line. What good is a passing test for a piece of functionality that does not do what the client wants?
– user8365
Apr 10 '14 at 16:55
@JeffO Having the test wouldn't excuse the functionality if it's not to spec. The implicit minimum standard is that a task isn't done unless it satisfies its functional requirements. Additional requirements, like testing, are applied on top of that. So client satisfaction is very important, in a "necessary but not (always) sufficient" kind of way.
– aroth
Apr 11 '14 at 0:02
2
2
I'm not sure I agree. There is not one-size-fits-all/universal definition of "done". However many organizations will indeed set an objective standard by which a task may be considered done. For instance, it's not uncommon to declare that a task cannot be considered done unless there are unit or integration tests (or both) to cover the new code. Or that no task is done until a second developer has reviewed the code. And so on. It doesn't always come down to just observable functionality. Especially for things like in-house development projects.
– aroth
Apr 10 '14 at 13:21
I'm not sure I agree. There is not one-size-fits-all/universal definition of "done". However many organizations will indeed set an objective standard by which a task may be considered done. For instance, it's not uncommon to declare that a task cannot be considered done unless there are unit or integration tests (or both) to cover the new code. Or that no task is done until a second developer has reviewed the code. And so on. It doesn't always come down to just observable functionality. Especially for things like in-house development projects.
– aroth
Apr 10 '14 at 13:21
@aroth - Not that it is a single definition, but the client or even in-house user's satisfaction is the bottom line. What good is a passing test for a piece of functionality that does not do what the client wants?
– user8365
Apr 10 '14 at 16:55
@aroth - Not that it is a single definition, but the client or even in-house user's satisfaction is the bottom line. What good is a passing test for a piece of functionality that does not do what the client wants?
– user8365
Apr 10 '14 at 16:55
@JeffO Having the test wouldn't excuse the functionality if it's not to spec. The implicit minimum standard is that a task isn't done unless it satisfies its functional requirements. Additional requirements, like testing, are applied on top of that. So client satisfaction is very important, in a "necessary but not (always) sufficient" kind of way.
– aroth
Apr 11 '14 at 0:02
@JeffO Having the test wouldn't excuse the functionality if it's not to spec. The implicit minimum standard is that a task isn't done unless it satisfies its functional requirements. Additional requirements, like testing, are applied on top of that. So client satisfaction is very important, in a "necessary but not (always) sufficient" kind of way.
– aroth
Apr 11 '14 at 0:02
add a comment |Â
up vote
2
down vote
Depending on the size of your company and where you fit in the heirarchy, it sounds like a cultural change could be in order.
I work for a large corporation, and before any significant milestone, particularly completion of a project, we are required to go through a formal peer review process. The person responsible for the work goes over it with a few technically knowledgable people - presumably including you and your boss - and everyone offers comments and suggestions of what needs to be fixed before this step can be declared complete. It would be easier to get your point across to your colleague with other people to back you up, or maybe you'll discover that you're the only person who thinks these changes are necessary. You should leave the meeting with a specific list of changes that need to be addressed to declare completion.
Adding these types of meetings are something that would need to be done across the board - not just when you think someone isn't doing their job. This means that your work should be subject to comments from others as well! If you're not in a situation to do this company-wide, then talk to your boss about getting this set up for your team. If this results in better products coming out of your group, the higher ups are bound to take notice and may even implement it in other divisions.
answered Apr 10 '14 at 13:15
David K
20.8k1075110
add a comment |Â
up vote
2
down vote
Depending on the size of your company and where you fit in the heirarchy, it sounds like a cultural change could be in order.
I work for a large corporation, and before any significant milestone, particularly completion of a project, we are required to go through a formal peer review process. The person responsible for the work goes over it with a few technically knowledgable people - presumably including you and your boss - and everyone offers comments and suggestions of what needs to be fixed before this step can be declared complete. It would be easier to get your point across to your colleague with other people to back you up, or maybe you'll discover that you're the only person who thinks these changes are necessary. You should leave the meeting with a specific list of changes that need to be addressed to declare completion.
Adding these types of meetings are something that would need to be done across the board - not just when you think someone isn't doing their job. This means that your work should be subject to comments from others as well! If you're not in a situation to do this company-wide, then talk to your boss about getting this set up for your team. If this results in better products coming out of your group, the higher ups are bound to take notice and may even implement it in other divisions.
answered Apr 10 '14 at 13:15
David K
20.8k1075110
add a comment |Â
up vote
2
down vote
up vote
2
down vote
Depending on the size of your company and where you fit in the heirarchy, it sounds like a cultural change could be in order.
I work for a large corporation, and before any significant milestone, particularly completion of a project, we are required to go through a formal peer review process. The person responsible for the work goes over it with a few technically knowledgable people - presumably including you and your boss - and everyone offers comments and suggestions of what needs to be fixed before this step can be declared complete. It would be easier to get your point across to your colleague with other people to back you up, or maybe you'll discover that you're the only person who thinks these changes are necessary. You should leave the meeting with a specific list of changes that need to be addressed to declare completion.
Adding these types of meetings are something that would need to be done across the board - not just when you think someone isn't doing their job. This means that your work should be subject to comments from others as well! If you're not in a situation to do this company-wide, then talk to your boss about getting this set up for your team. If this results in better products coming out of your group, the higher ups are bound to take notice and may even implement it in other divisions.
answered Apr 10 '14 at 13:15
David K
20.8k1075110
Depending on the size of your company and where you fit in the heirarchy, it sounds like a cultural change could be in order.
I work for a large corporation, and before any significant milestone, particularly completion of a project, we are required to go through a formal peer review process. The person responsible for the work goes over it with a few technically knowledgable people - presumably including you and your boss - and everyone offers comments and suggestions of what needs to be fixed before this step can be declared complete. It would be easier to get your point across to your colleague with other people to back you up, or maybe you'll discover that you're the only person who thinks these changes are necessary. You should leave the meeting with a specific list of changes that need to be addressed to declare completion.
Adding these types of meetings are something that would need to be done across the board - not just when you think someone isn't doing their job. This means that your work should be subject to comments from others as well! If you're not in a situation to do this company-wide, then talk to your boss about getting this set up for your team. If this results in better products coming out of your group, the higher ups are bound to take notice and may even implement it in other divisions.
answered Apr 10 '14 at 13:15
David K
20.8k1075110
answered Apr 10 '14 at 13:15
David K
20.8k1075110
answered Apr 10 '14 at 13:15
David K
20.8k1075110
answered Apr 10 '14 at 13:15
David K
20.8k1075110
20.8k1075110
add a comment |Â
add a comment |Â
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%2f22491%2fis-there-a-polite-way-to-say-that-a-colleague-is-too-relaxed-with-the-definitio%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
4
My office had problems similar to this in the past. It took a huge team oriented movement to get past this problem. We had several meeting through the span of several weeks arguing over what the definition of done for any given task should be. The result was we had well defined definition of done. The way you reach that with your team will be unique, but you cannot single one person out, it has to be a team effort. Take into account testing, refactoring, requirements...etc.BestApproachIsMakeTheTeamAwareOf the TEAM problem, andtryto mention the importance, From there a manager should handle it.
– TheOneWhoPrograms
Apr 10 '14 at 8:59
2
If I were the superior, I'd definitely throw the ball back at your colleague. Having said that, my definition of "done" may be limited to doing the absolute minimum to get it declared as "done". If the program does what the specs say, then it meets the minimum definition of "done" This is not to say that meeting the minimum definition of "done" is optimal for the task, the project or the firm. Far from it. The superior will have to decide what is meant by "done", set policy on it and ultimately sign off on the tasks and projects as "done", taking into account any disagreements.
– Vietnhi Phuvan
Apr 10 '14 at 10:24
3
Strictly speaking, refactoring has no impact upon observable behavior. So "refactoring needs to be done" is not an indication that a task is not done yet. Unless that task was "refactor the code". If the functional requirements are met, then the task will likely be considered "done". The amount of refactoring needed is a reflection of accrued technical debt more than it is a modifier on the level of "doneness" of the task.
– aroth
Apr 10 '14 at 13:14
What software is ever really done? Software may be abandoned, rarely does it ever get to the point of perfection.
– JB King
Apr 10 '14 at 20:34