Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Maintaining code quality when nobody cares

mkdev.me

Post reply on HN
Print view View original

51–60 of 245 posts

Re: Maintaining code quality when nobody cares

#51

Post by kabes »

chii wrote: post #17
pgsandstrom wrote: post #13

> It turned out that the project I was invited to started as early as 2014. Do you think it means that it’s big and complicated? Then you’re right. And it’s also really old. Is it just me, or is less that four years not "really old"?

the javascript mentality! software isn't old until it breaks 10 yrs!

It's just that the javascript language, frameworks and ecosystems have seen massive changes over the last couple of years. C for example hasn't seen this change. So yeah, C code from 5 years ago would look the same if written today, while javascript of just 2 year old might seem outdated.

Re: Maintaining code quality when nobody cares

#52

Post by troels »

crdoconnor wrote: post #20
dep_b wrote: post #14

You need to get the programmers together and agree on a coding guideline, a linter and other architectural fundamentals. Then the gardening phase begins, which means no refactoring or warning or style fixes unless you touch the code to do something meaningful like a feature or bug fix. Leave everything you touch better than before. Dissolve big classes and functions into smaller ones. Write a test or two for the smal…

IME linting picks up about 99% fluff (ooh look there's some whitespace on a blank line) and 1% potential issues highlighted (usually minor). The reason people like to default to linting when "fixing code quality issues" is purely because it's 100% objective and measurable, not because it picks up the truly important issues. It doesn't. Edit: I am aware that coders have OCD impulses which can be sated with a linter, b…

Depends. Some programmers have absolutely no hygiene wrt formatting. You'd want that sorted for readability.

But the bigger point is that you reduce merge conflicts since you won't have all sorts of unrelated formatting changes mixed in with the real changes.

Re: Maintaining code quality when nobody cares

#53

Post by justherefortart »

troels wrote: post #50
justherefortart wrote: post #43

Earlier quoted context omitted.

My company is hiring a company for the 5th or so time to outsource IT to this new wonder app that will replace us. It's being built in Cold Fusion. Lmfao, 22 years old out of the gate. So far they're about 2-3m in trying to replace us. Never gets far. Worst managed company I've ever seen. And as a consultant/contractor for 25+ years I've seen a lot of horribly run companies.

CF still exists?

Apparently. I just started laughing when I heard about it. I'm going to pitch an ASP (classic) project next!

Re: Maintaining code quality when nobody cares

#55

Post by bunderbunder »

crdoconnor wrote: post #20
dep_b wrote: post #14

You need to get the programmers together and agree on a coding guideline, a linter and other architectural fundamentals. Then the gardening phase begins, which means no refactoring or warning or style fixes unless you touch the code to do something meaningful like a feature or bug fix. Leave everything you touch better than before. Dissolve big classes and functions into smaller ones. Write a test or two for the smal…

IME linting picks up about 99% fluff (ooh look there's some whitespace on a blank line) and 1% potential issues highlighted (usually minor). The reason people like to default to linting when "fixing code quality issues" is purely because it's 100% objective and measurable, not because it picks up the truly important issues. It doesn't. Edit: I am aware that coders have OCD impulses which can be sated with a linter, b…

I agree, linting doesn't pick up much. But, at places I've worked where the codebase was kept linted, the humans did a better job of catching bugs in code review.

My guess is that, when you have a cosmetically messy code base, people start to develop a lower standard for what counts a understanding the code they're reading. Probably as a self-preservation mechanism. There's only so much time in a day.

Re: Maintaining code quality when nobody cares

#56

Post by tboyd47 »

> Code review at the end of the task.

This is something I still struggle with. I think it's a result of an open source tool (GitHub) bringing bits of culture along with it.

In open source world, all contributions are entirely voluntary, and most follow the Benevolent Dictator For Life form of governance. So you do a bunch of work, and you submit a polite request for the BDFL to pull your work into the project. He or she may decline your Pull Request, request a long list of changes, or just wait ten years to give any response at all.

In a business setting with hourly pay, deadlines, and co-workers chosen for you, not by you, it makes less sense. People tend to wait until the last minute to give or request feedback which leads to a lot of thrown-away work. Unfortunately, willingness to throw away work becomes a mark of pride at some places. Maybe enterprise projects need some kind of "managed push" system instead of a "pull request" system.

Edit: "Unfortunately, willingness to throw away work becomes a mark of pride at some places." to elaborate, the thing that makes this unfortunate is that the person assumes that throwing away work is necessary for code quality to stay high. By requesting feedback at intervals (which is what the author of the article recommended), you can avoid throwing away work without sacrificing quality.

Re: Maintaining code quality when nobody cares

#57

Post by detaro »

tboyd47 wrote: post #56

> Code review at the end of the task. This is something I still struggle with. I think it's a result of an open source tool (GitHub) bringing bits of culture along with it. In open source world, all contributions are entirely voluntary, and most follow the Benevolent Dictator For Life form of governance. So you do a bunch of work, and you submit a polite request for the BDFL to pull your work into the project. He or…

> Maybe enterprise projects need some kind of "managed push" system instead of a "pull request" system.

What would you do different in "managed push"?

Re: Maintaining code quality when nobody cares

#58

Post by jlongster »

aalleavitch wrote: post #47
dep_b wrote: post #14

You need to get the programmers together and agree on a coding guideline, a linter and other architectural fundamentals. Then the gardening phase begins, which means no refactoring or warning or style fixes unless you touch the code to do something meaningful like a feature or bug fix. Leave everything you touch better than before. Dissolve big classes and functions into smaller ones. Write a test or two for the smal…

This is absolutely the situation I am in right now, and I desperately need all the guidance I can get. We’re talking thousands of lines of React components that rely regularly on manipulating global js variables, mixed with MVC 5 written in Razor delivering variables in script tags, mixed with outdated jQuery, that’s all just concat’d together with gulp and that hasn’t seen a refactor in years of changing hands with…

You need to tell your manager that it's simply impossible to both clean all that up and also make progress on the project. You need to stop the erosion in order to fix it; fixing will require fundamental changes that will absolutely block progress. If aren't able to freeze the project, your cleanup progress will be constantly thwarted by new ugly hacks.

There's just no way around it. If your managers won't freeze the project until you make meaningful progress, you're going to be stuck working with this ugly code for a long time. Try to convince them that in the long-term a cleanup will pay dividends. Without their support though, you won't get anywhere.

If you're able to freeze the code for a bit, it sounds like it might just be quicker to rewrite some parts like the CSS. Don't take on the whole project at once - find pieces that can be rewritten individually, even if it's a large part like all the styling.

Re: Maintaining code quality when nobody cares

#59

Post by pjc50 »

pgsandstrom wrote: post #13

> It turned out that the project I was invited to started as early as 2014. Do you think it means that it’s big and complicated? Then you’re right. And it’s also really old. Is it just me, or is less that four years not "really old"?

Hah! The code I'm working on at the moment is full of banners saying

// Copyright (C) 1991 - 1999 Rational Software Corporation

I think it actually originated in 2002 and those are junk left over from the use of Rational Rose code generation. Revision history only goes back to 2007.

Re: Maintaining code quality when nobody cares

#60

Post by dentemple »

sametmax wrote: post #34
pgsandstrom wrote: post #13

> It turned out that the project I was invited to started as early as 2014. Do you think it means that it’s big and complicated? Then you’re right. And it’s also really old. Is it just me, or is less that four years not "really old"?

Not old. The author is probably young. Or a js dev. Or both.

The author clearly explained his background in the article.
Post reply on HN