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.

  • 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. Commented Apr 10, 2014 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. Commented Apr 10, 2014 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
    Commented Apr 10, 2014 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
    Commented Apr 10, 2014 at 20:34

3 Answers 3


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.


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
    Commented Apr 10, 2014 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
    Commented Apr 10, 2014 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
    Commented Apr 11, 2014 at 0:02
  • This feels a bit too "the customer is always right" for my tastes, and to put it bluntly we know for a fact that's just bullshit. Customers are wrong idiots all the time.
    – FeRD
    Commented Oct 14, 2022 at 17:50

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .