> don't care what your code looks like if you did not achieve a good end-product.
I do care if your code is a mess if other engineers have to maintain it.
I do care if your code is a mess if other engineers have to maintain it.
My point is that "good code" should be prioritized behind a good product. The purpose of code is to deliver a product, not to be well-factored or to embody certain principals. If your product is bad, your code is already categorically bad, no matter how beautiful it is.
But what if you have a component here or there with well defined, well tested interfaces, but internally it's a bit of a mess? Or what if you hack together a proof-of-concept for a new feature to get it out the door and see what users do with it before investing a lot of time in making it perfect? Those kinds of things can help your organization move faster.
As with most things, clean vs messy code is not a binary. It's the sum of a lot of individual value judgements about when it's pragmatic to focus on code quality.
Even so, I am inclined to argue that in most cases the exact opposite is true. That is, it is actually “easier” to create a “good product” with a messy codebase, because in most cases “easier” and “good product” are understood by primary stakeholders to mean business value at this moment.
- One coder writes his product with a high quality code base.
- Another coder sits next to 3 users of his product, and hacks stuff in as fast as possible.
I would bet on the 2nd one for having the better user interface.