Live data from Hacker News

Maintaining code quality when nobody cares

mkdev.me

11–20 of 245 posts

Re: Maintaining code quality when nobody cares

#11
post #6

Code quality depends on you. If you are maintaining the system then for your own sanity, clean it where you can. If you are writing the system for someone else to maintain, clean it where you can, because you will probably be the poor sod who will have to maintain it later on. If you can't clean it now, write down everything you know about the system, all those little annoying assumptions that nobody else has documen…

If you dont get the time necessary- lie to your clueless superiors- tell the story about the complicated feature, that needs hours more- they will never understand how much a well made library will save them future time, so you are actually helping a clueless fool to do a good decision with that little lie.

The downside to this approach is people. You risk other (well meaning or otherwise) developers trying to help fix your misunderstanding or telling your supervisor that you need help. Others may need to be in on it and sometimes that sort of environment breeds cut-throat behavior. If the business has the power to dictate unreasonable requirements people that break ranks to tell them what they want to hear can gain a political advantage.

Re: Maintaining code quality when nobody cares

#12

Some things I've learned about code quality in organizations where the quality is terrible: 1. The problem starts with culture. These organizations are run top-down by people who don't understand coding. Sometimes they are ex-engineers, but that's usually about as good as non-engineer. 2. These organizations are systemically incapable of determining good work from bad. Who on the team is performing and who isn't? The…

Yes, you summed up perfectly what I've been experiencing in my professional career for quite some time now.

Re: Maintaining code quality when nobody cares

#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 smaller side effect free function you just created.

It takes a ton of time and patience but every week the kraken loses a tentacle. And once most code feels untangled you can embark on a refactor since all of the parts are movable now.

Re: Maintaining code quality when nobody cares

#15

> 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.

Re: Maintaining code quality when nobody cares

#16
post #3

Quality means doing it right when no one is looking. - Henry Ford

A clever quote saves us from having to think! (paraphrased from some original quote I can't remember)

Yes, but in this case someone else did the thinking for you and it is actually pretty accurate. If the only time you care about quality is when you are being checked, audited or supervised then it will not work.

Quality needs to be infused all across the board and needs to be reinforced from the management downwards throughout the whole organization, not just in the quality control department.

So Ford was definitely on to something and beat mr. Demming by a couple of decades on that particular insight. It's no surprise that both of them had a lot of these insights in the automotive industry to begin with, where warranties can very rapidly eat up the profit margin on the sale.

Re: Maintaining code quality when nobody cares

#17

> 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!

Re: Maintaining code quality when nobody cares

#18

Some things I've learned about code quality in organizations where the quality is terrible: 1. The problem starts with culture. These organizations are run top-down by people who don't understand coding. Sometimes they are ex-engineers, but that's usually about as good as non-engineer. 2. These organizations are systemically incapable of determining good work from bad. Who on the team is performing and who isn't? The…

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

Re: Maintaining code quality when nobody cares

#19
post #6

Code quality depends on you. If you are maintaining the system then for your own sanity, clean it where you can. If you are writing the system for someone else to maintain, clean it where you can, because you will probably be the poor sod who will have to maintain it later on. If you can't clean it now, write down everything you know about the system, all those little annoying assumptions that nobody else has documen…

If you dont get the time necessary- lie to your clueless superiors- tell the story about the complicated feature, that needs hours more- they will never understand how much a well made library will save them future time, so you are actually helping a clueless fool to do a good decision with that little lie.

People have different situations in life and the range of options that you have as an employee can vary pretty dramatically. However, here's how I tend to cope with these situations (in order of preference):

1. If I don't get the time to do what I think is necessary, then I lobby to make sure that it's my decision about how much time it takes. You're not going to get handed this on a silver platter, but the main argument is that as a developer you are making a good salary. The person paying that salary should get the best value from that money. If you have to do your job in handcuffs, you're not going to be able to give the best value.

2. If I'm not in a political situation to do #1 (and you should probably try to make sure you are before you actually stick your neck out), then I will note the constraints I have to work under. Making a project succeed when everything goes exactly as you want it to is relatively easy (well, TBH, I think it's never actually easy, but you get my point). What makes a great developer is making the project succeed even when you don't have everything your own way. So find a way to succeed with the constraints that you have. If you fail, make sure to make it obvious which constraints are causing the most problems. Usually after you fail you can get some extra leeway on those issues. Work on the issues one at a time, most important first. Eventually you can usually promote yourself to option #1.

3. If I can't do #1 and there is some reason why #2 fails (and I can't fix it), then I will go elsewhere. No point in sticking around in a place where you can't succeed. Wish everybody great luck. Express remorse that you couldn't get the kind of success that everybody wanted. Thank people for the opportunities that you had.

4. If I can't go because I have no other job, or I need to stay because my visa says so, or my spouse will go crazy from stress if I switch jobs, or a million other possible reasons... I'll keep working and keep studying exactly what's causing the problems. It's easy to conclude, "Joe is breaking everything. I hate Joe" (I only picked the name Joe because to the best of my recollection, I've never worked with someone named Joe). But you're stuck and you might as well learn about the situation in more detail. Wait and watch. I hate waiting. Man, do I hate waiting. But eventually it will pay off. Opportunities are out there. Your job is to recognise them.

That's it. Don't lie. You'll only get found out and then make your job a hundred times harder. Don't get dragged into petty politics. The job is hard enough without drama. Play it straight and give everyone the best chance they have to understand what you are doing and cooperate with you. Don't undermine people. Just do your best. It's not always easy sailing, but learn how to navigate rough waters and you'll be fine.

Re: Maintaining code quality when nobody cares

#20
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, but priority #1 when fixing spaghetti code is unraveling the spaghetti, not sating your need to see }s in a place that makes you feel better.

Post reply on HN