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

41–50 of 245 posts

Re: Maintaining code quality when nobody cares

#41

Post by jacquesm »

philbarr wrote: post #38
jacquesm wrote: post #15

Earlier quoted context omitted.

The number of years a piece of software has been alive is not always a good indicator of how old it is. It can be 2 years old and in outright legacy territory. Some people are working hard to replace one legacy project with another. Software does not age well when it isn't constructed properly.

My favourite quote from, "Working Effectively With Legacy Code" by Michael Feathers: "They're writing legacy code, man!"

I've - unfortunately - seen a case like that a couple of weeks ago. Very sad, moreso because they did not realize they were simply replaying the past. With all the best intentions of course.

Re: Maintaining code quality when nobody cares

#42

Post by petagonoral »

crdoconnor wrote: post #26
carlmr wrote: post #18

Earlier quoted context omitted.

So what is the prescription to find a company that doesn't check these 5 boxes?

In general the companies that don't both A) pay better and B) are located in tech hubs / do remote work. So, go for more money, prefer remote or in a tech hub. You can also ask during interview about the coding experience of the manager you will report to. Usually they are up front about it. If you turn them down, do us all a favour and let the company know that was why (more coding managers and fewer MBAs please!).…

> You can also ask during interview about the coding experience of the manager you will report to.

Yes, for tech leadership. No for people management.

Simply put, too many people in people management positions who were "technical" x years ago. This leads to them making technical decisions that their team should be making, which they absolutely should not be doing.

Re: Maintaining code quality when nobody cares

#43

Post by justherefortart »

jacquesm wrote: post #15
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 number of years a piece of software has been alive is not always a good indicator of how old it is. It can be 2 years old and in outright legacy territory. Some people are working hard to replace one legacy project with another. Software does not age well when it isn't constructed properly.

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.

Re: Maintaining code quality when nobody cares

#44

Post by yoodenvranx »

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"?

> Is it just me, or is less that four years not "really old"?

In the JS world 4 years is very old bu in the C/C++ world 4 years are still quite fresh.

Re: Maintaining code quality when nobody cares

#45

Post by crdoconnor »

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…

You need to flip the script on the problem. It's no longer a technical problem, it's a management problem.

Management problems are solved with spreadsheets that show concrete numbers going up or down.

At the beginning of each sprint ask the manager what % of time developers should spend fixing quality issues on each story after the story is complete. 0%? 30%? 50%? Track it. Graph it.

At the end of the sprint ask developers "how do you feel about the quality of the code base this sprint? [ 0 dangerously unstable --- 100 - clean and perfect ]. Track it and graph it.

Track what % of stories in the sprint are "code quality" stories (e.g. upgrade node). Create a graph showing four consecutive sprints with 0% time allocated to code quality stories.

After about 4 sprints of this, provided you were reasonably open and transparent about what you were doing, you'll probably have a slightly freaked out product manager who is newly cognizant of the need to properly allocate time to "quality".

If it turns out he's an idiot who ignored your little game, well, you've amassed documentation necessary to make his bosses start considering his termination and replacement.

Don't fuck around with this stuff though - you can invite all sorts of problems if you're not careful with this approach. Assume everybody is honest and has good intent until proven otherwise.

Re: Maintaining code quality when nobody cares

#46

Post by Fradow »

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"?

There is a real difference between a properly maintained, up-to-date project that happened to be started four years ago, and a project that was started four years ago, has never seen any dependencies update (not even security fixes), and is dirty hack over dirty hack.

By the tone of the article, the author is clearly talking about the second kind.

Re: Maintaining code quality when nobody cares

#47

Post by aalleavitch »

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 no style guide. The company started in 2004 and I swear some of this code is still floating around from the day it started. We have three sets of scss breakpoints, three or four layers of “common.scss” files that act like a piece of furniture that has been painted over dozens of time (with shit like * {padding:5px} floating around), and an unknown amount of dead code. There’s lines written back-to-back with vastly different styles (with a random distribution of semi-colons and arrow functions and etc), and major global variables named with misspellings. And while I clean this all up, I am expected to continue pushing out features and addressing serious bugs with stop-gap measures.

Please advise.

Re: Maintaining code quality when nobody cares

#48

Post by dwc »

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"?

Of course it's not really old. Though in my experience age has only a loose correlation to overall code quality. Some really old programs were well architected to start and have been carefully maintained. OTOH, I've worked with devs who are one-person technical debt factories, and allowed to work on relatively young and sparse applications will quickly make it an unmaintainable monstrosity.

Re: Maintaining code quality when nobody cares

#49

Post by hiccuphippo »

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"?

That's like 20 years in JavaScript years.

Re: Maintaining code quality when nobody cares

#50

Post by troels »

justherefortart wrote: post #43
jacquesm wrote: post #15

Earlier quoted context omitted.

The number of years a piece of software has been alive is not always a good indicator of how old it is. It can be 2 years old and in outright legacy territory. Some people are working hard to replace one legacy project with another. Software does not age well when it isn't constructed properly.

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?
Post reply on HN