Should Product care about the quality of your code?

Nir Radian
Sep 6, 2018 · 4 min read

It is a known story. Product want you to push your feature when it is ready. Its ready when they think its ready. They reviewed it, and decided that the button looks like the mock up and clicking it does what they told you it should do.

“When do you expect it to be in production?” They ask. “Two days, I haven’t finished cleaning up the code, I’m not satisfied with all the tests and I need to document it.”, you replay.

“But the deadline is tomorrow, and it looks ready. Push it.”

What now? The Product team has a point. There’s a deadline, and it looks ready. Why should they care if you are [doing something that Martin Fowler will frown upon] but is completely functional?

“Fine, but I need two days next sprint to finish this up” , you say.

“Sure, no problem”.

Next Sprint starts, this is prioritized as “nice to have”, there is a critical bug discovered by the highest paying customer and the code is left as it is.

Eternal Suffering in Hell ensues.


Does this sound familiar? Maybe you’ve also tried:

  • Explaining the risk associated with not going back and improving the code to your Product team in hopes that this is prioritized more effectively
  • Putting aside story points in the future for technical debt
  • Skunkworking at night to cleanup the code because you are just that type of committed individual that cannot live with existence of poorly written code. (Where can I get in touch with you for a position at our company?)

Only the last option is somehow even relevant. If you believe that the first two are actual options, then we don’t agree on a key issue:

Only Developers can decide when something is ready.

Product can help with refining requirements, they can help with validating ideas about the end users, they can also decide what the deadline is, whether to go forward or scrap the whole project, but they do not decide when something is ready.

Product doesn’t care about the quality of your code as much as you do, and they never will.

So truly, its a conflict with ourselves. On the one hand, we want our code to be clean. On the other, we do like delivering on time. Sometimes its hard for us to come to terms that we simply did not meet the deadline.

I’ve followed with some tips that can help in general when you need to meet a coding standard and also have tight deadlines, but in the end — we need to be honest with ourselves and tell Management/Product that:

“No, its not ready. We need to move the deadline, relax some of the requirements, or pull a resource from another project.”

Saying this comes with a heavy price, but lessons should be learned and at least we’re not lying to ourselves about our development capacity (which is probably much slower then we think it is).

The question remains — how to create an environment where you can admit to not being ready for the sake of maintaining your coding standards. My best response to this is — practice. See what the repercussions are. A place where developers are berated for not meeting deadlines because they haven’t finished writing proper tests or cleaning up or documenting properly — that’s the place where the code is rotting and continuously needs fixing and patching and refactoring.


With all that said, here are a few tips that may help with ensuring that only code that is up-to-par with your standards is pushed.

  • Don’t push half written code. There should be a branch where everyone agrees is only updated with code that is “gold”. You can have any number of feature branches you like, but a reviewer should accept only “gold” code into your master branch. No stubs or placeholders, no todos, no “missing tests”. Deployed branches should fork from this branch and not any other.
  • Compartmentalize. Focus on the visual element to begin with. Eliminate risk by reviewing with the Product Team. Finish cleaning up that branch, close it and forget about it. Then focus on the action, API, or whatever. Don’t use the visual element that you worked hard on, it doesn’t exist. Use a debug view, use tools, use a mock. Finally, integrate. If things don’t work off the bat, go back to step 1, you must have had a wrong assumption somewhere.
  • Shift Left. “Write a little test, add a little code, get down tonight.” Don’t leave tests till the end, don’t start with all the tests. Same for cleaning up and documentation.
  • Let Go of the Future. Some code will live for ages and become part of your legacy, some will be changed next week. You can’t make everything future proof. You should know when to put a stop to over engineering. Solve the problem at hand and no more.

These are all hard things to do, undoubtedly. This can’t be done with a lot of flexibility when necessary but the guidelines make sense and should be valuable even when not applied strictly.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade