5 ms·
> 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.
by fredrb 8y ago
> 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.
- skohan 8y agoI'm not saying clean code is not desirable. Code which is easy to maintain and modify is absolutely better than messy code. 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.
- ensiferum 8y agoBut it's really difficult to make a good product and good product experience on a messy code base. Quality code leads to better product IMHO. (of course good quality code base can still suffer from badly designed UX)
- skohan 8y agoThe devil is in the details. Sure, if your codebase is systemically messy, it's probably going to take forever to get anything done, and you will probably end up with bugs in the final product. 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.
- koonsolo 8y agoI would love to do the following experiment: - 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.
- kingdomcome50 8y agoWithout fully qualifying what “easier”, “good product”, and “good experience” mean as well as delineating project constraints such as time, business value, and life it’s not possible to truly have this discussion. 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.