3 ms·
Your right, a large part of the problem is that there isn't a quantifiable way (outside of things like bugs/kloc, which are themselves suspicious) to identify a
by StillBored 7y ago
Your right, a large part of the problem is that there isn't a quantifiable way (outside of things like bugs/kloc, which are themselves suspicious) to identify a clean code base. I believe that is because much of it is personal preference, the same way some people find single family homes optimal while others like high rise condos. One person may think that adding some "clean python" code to an existing pile of bash scripts "cleans" it up while another may think that keeping the code base using a single language is cleaner while trying to minimize churn and bugs.
Bottom line, I frequently question much of what is being sold as developer productivity these days. It seems in my experience "this code is ugly/garbage/etc" is simply translation for "I don't understand much of this code". Engineers that truly understand the code base just go and fix it, usually with commits that are either small one or two line bug fixes with long commit messages describing how the system is failing and what is actually being fixed. Alternatively, they have "cleanup" patches that have extremely high removal/add line ratios which are replacing large chunks of difficult to understand code with small pieces that are easier to understand, and long commit messages detailing where the redundant functionality was. Very rarely are these changes to a different language/toolkit. But the evidence of skill in both these cases just about never include followup patches to "fix" new problems introduced by the previous round of fixes.
- kqr 7y ago> outside of things like bugs/kloc Since #bugs is strongly correlated with loc I'm thinking this might turn out to be very low in signal -- so much so that you might instead just throw a dice to determine the "code quality" of each project, if using this metric is the alternative.
- bdavis__ 7y agoyou may need to look at bugs/ksloc as more of an enterprise measure than one for an single project. when it gets down to it, this is the measure that will tell you if your organization is 'improving'; end of the line reducing your defect rate is one of the most valuable things to accomplish.
- kqr 7y agoAssuming it's more noise than signal, increases or decreases to that measure don't tell me anything about actual improvement. I'm all for reducing the defect rate, I'm just not convinced optimising bugs/kloc is meaningful.
- StillBored 7y agoWell anything done directly to influence bugs/kloc is bound to throw the whole thing off. I think the parent here was mostly interested in discovery rate, which also can be influenced by hiring/firing test and QA, or for that matter gaining/losing customers that use the product. And everything being mostly equal, it could be a reflection of code maturity more than anything. The more mature product may have a higher bug/loc ratio only because more of the bugs have been found. Which is why I mention there are metrics, but they all seem to have major problems.
- dasil003 7y agoYes, I’d say Chesterton’s Fence often looms large in these cases. While “build one to throw away” is often ideal it is contingent on deep understanding first, and even then there is significant risk of overlooking major flaws in a new untested design. In practice I think the best approach is to primarily refactor incrementally in service of ongoing work; management doesn’t need to approve this, you just build it into your estimates as an IC. If technical debt is being taken on call it out early and loudly and secure cleanup budget in advance if possible. Beyond that recognize that big rewrites are rarely justifiable. Even if a code base is complete shit, it’s most likely not worth it to rewrite. As an engineer this reality may put you in a lose-lose situation. Learn to separate your personal feelings and innate desire for order, and make an objective call on whether the code is workable and start looking for a new job if not.
- vbezhenar 7y agoBut you can just rewrite that complete shit and keep your current job. And rewriting is very fun. I did it multiple times and don't understand those who're ready to switch job or work on a bad code. Isn't it better to embrace your desire for order than to fight yourself? There are some people who don't care, good for them.