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

171–180 of 245 posts

Re: Maintaining code quality when nobody cares

#171

Post by s73v3r_ »

noxToken wrote: post #39
jrochkind1 wrote: post #21

Earlier quoted context omitted.

The problem here is that you're making the organizational culture _worse_ while you make the code better. And it's organizational dysfunction that led to your situation in the first place. It's a dysfunctional organization that doesn't let you write quality code without lying (assuming you are correct that this is ultimately counter-productive for the organization's goals), and most every dysfunctional organization I…

So what's the alternative to lying for what you hope is the greater good? This is the advice that I give my colleagues who, after exhausting all other methods, try to squash technical debt before a 1 hour task becomes a 5 hour task. Leaving the job doesn't solve the problem (though it may save your sanity). In fact it might make it worse, because the leaving person is likely taking tacit knowledge with them. I'm not…

If the organization doesn't care about code quality, then they don't deserve talented engineers with domain knowledge.

Re: Maintaining code quality when nobody cares

#172

Post by dep_b »

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…

First agree on what it should actually be and document that. Make sure nobody commits anything that makes the codebase worse. Don’t refactor but clean first, and only while delivering value.

Re: Maintaining code quality when nobody cares

#173

Post by geezerjay »

WorkLifeBalance wrote: post #101
aalleavitch wrote: post #47

Earlier quoted context omitted.

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…

Personally I thrive in this kind of environment, it's a kind of comfortable chaos. MVC5 is positively modern compared to many of the products I've worked with which have included (within the last 5 years) VB6 winforms but mostly aspx webforms. Understand that previous developers might not know what a DOM is have likely written ad-hoc jquery snippets, included 3 different versions of jquery-ui until they happened acro…

It should be noted that more often than not there are strong reasons besides ignorance and incompetence for a project to arrive at a certain state.

https://en.m.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fen...

It shoud be stressed that a developer should not assume all his predecessors were wrong just because he doesn't understand why some stuff ended up being the way it is. The world is packed with developers who proud themselves of fixing things that were never broken, and in the process break stuff.

Re: Maintaining code quality when nobody cares

#174

Post by boomlinde »

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…

I don't necessarily see code reviews as the problem here. I think it's a very important aspect of development that unfortunately seems first in line to get cut back when other parts of the organization fail, when for the sake of quality I believe that the organization should be designed to always accommodate it.

For example, you mention waiting until the last minute and throwing away work. If this is such a big deal, maybe the units of work are too big or too loosely defined. Loosely defined as in "eh, we never needed this in the first place" or big as in "sorry about that but your 2000 LOC commit just isn't the right approach". Maybe github style reviews/pull requests are also not the best way to go about it. IMO the github style is pretty weird and shouldn't be conflated with reviewing in general.

At my current workplace, we use gerrit to review every commit. The only way that they'll ever get to master or a shared development branch is if they get a +2 vote. Maybe this is closer to a "managed push"? It's not rare that someone finds an issue, and when that happens it's very rare that it means scrapping the entire patch, and when that happens, it's usually a very small patch for a problem/feature that ended up being fixed elsewhere, so I definitely don't think it's a waste of time. Instead I am grateful that many of the patches didn't enter the codebase in their initial state.

Re: Maintaining code quality when nobody cares

#175

Post by rocky1138 »

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…

Rule 1: No new bullshit hacks make it in.

Rule 2: One bullshit hack must be removed per sprint.

Over time, you'll have better software.

Re: Maintaining code quality when nobody cares

#176

Post by boomlinde »

hawski wrote: post #79
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…

What I don't like in "commercial" code reviews is that most reported issues are there just to fill space. It's busy work. There is this formal comment system. So instead of fixing this typo in a code comment directly reviewer writes a comment. Code style issues that arise, because of absence of a tool like go-fmt also warrant a comment. That's sad. There are meaningful comments, but usually people have to fill their…

On the other hand, pointless bikeshedding quickly gets mutually tiresome in a setting where every line of code is reviewed in small increments. I also like to address these tiny inconsequential hangups politely when I disagree that they're important. Let's say some guy suggests changing "name" to "someNeedlesslyDescriptiveName" and I'll point out that it's already clear what it is because it's the only variable in the needlesslyDescriptive function.

Re: Maintaining code quality when nobody cares

#177

Post by jimjimjim »

i used to be a software archeologist at a previous job. dig a small hole and uncover the artifacts and ruins of a previous project civilization.

please, for humanity, write documentation. even better if it's after the code is written. why does the payments-smart-broker have a direct connection to the translations database if it doesn't have a ui?

Re: Maintaining code quality when nobody cares

#178

Post by dasmoth »

dep_b wrote: post #169
dasmoth wrote: post #98

Earlier quoted context omitted.

At times it becomes hard to see what code you wrote and what somebody else wrote, which is a good thing. I suspect this is the big point of disagreement between lint-advocates and many of those who are dubious. I generally don’t see big wins from collectivising code, and on the who prefer to treat people I’m working with as individuals who can be interacted with 1:1 vs an amorphous “the team” writing “the codebase”.

Usually there’s a style that’s mandated by large authorities like C# formatting is mandated by Microsoft and JetBrains. Copying their style gets you there for 80%. The rest is whatever you agree on and usually not something that bothers me. If you’re the guy that thinks having a 300 line function in an 8000 line class is just an individual way of expressing yourself you’ll have to fight me. If you think real tabs is…

The fact that you’ve named an IDE vendor rather emphasises that there is a substantial gray area. By no means everyone wants to use an IDE (let alone that specific one...)

Re: Maintaining code quality when nobody cares

#179

Post by Clubber »

tmorton wrote: post #103
jlongster wrote: post #58

Earlier quoted context omitted.

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…

I disagree with most of this comment, but I think it's an interesting and valuable discussion. Here's where we agree: You need to stop the erosion in order to fix it. Every developer on the project needs a shared vision of what "better" means. For example, the parent comment mentions React components that manipulate global variables. First of all, everyone agrees to stop doing that, and agrees on the alternative (use…

That's what I've always done. Fix it when you see it. Eventually, you have a clean codebase.

Re: Maintaining code quality when nobody cares

#180

Post by ravenstine »

zoul wrote: post #168
nightski wrote: post #166

Earlier quoted context omitted.

A contrary opinion based on experience - instead of focusing so much on how bad the code is take the time to get to know your coworkers better. Talk with your manager and the business leaders about the business. Learn more about the business you are in and how your code makes an impact to that business. At the end of the day the goal is not to produce clean code. It's to make your company successful. I'm not saying c…

I agree, but it seems to me that being dragged down by technical debt is massively more common in our industry than missing important deals because of excessive emphasis on clean code?

Our industry is pretty hilarious in this sense. In school, it's expected that you go through multiple drafts to complete an essay, and usually those who skipped that process paid a penalty. Publishing is a high speed industry, but time is still set aside for revisions and editing. These same standards seem to rarely be applied in programming, I guess because our work isn't seen as writing communication. We make computers "go". Because of that, we are too often writing and reading each others' rough drafts.
Post reply on HN