Is there a polite way to say that a colleague is too relaxed with the “Definition of Done”?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.