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

71–80 of 245 posts

Re: Maintaining code quality when nobody cares

#71

Post by eitland »

jimmy1 wrote: post #22
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.

In my opinion, when speaking of "legacy software", we should place a stronger emphasis on the actual meaning of the world legacy rather than the usual pejorative. Meaning that: this software has created a "legacy", in some form or fashion. Whether that legacy was it was used in the past to build the business, it paved the way for some standard or better practice, or it simply outlived it's time. Downvotes are usually…

Like it or not but legacy has taken a new meaning in software.

I think it is Michael Feathers who defines it as code without tests in "Working Effectively With Legacy Code".

(That said, I didn't downvote you and I'm also tired of the abuse of the downvote button. I think in your case they downvoted because it seemed like unproductive nitpicking.)

Re: Maintaining code quality when nobody cares

#72

Post by swaqny »

mikekchar wrote: post #19
Pica_soO wrote: post #6

Earlier quoted context omitted.

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 argu…

https://www.hello123.com

Re: Maintaining code quality when nobody cares

#73

Post by tboyd47 »

pjc50 wrote: post #61
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…

> willingness to throw away work becomes a mark of pride at some places Is this a typo for "willingness"? Code review is important not just for preventing junk from entering the codebase but for ensuring that someone else has seen the thing and has some idea of how it works. I agree that "pull request" is the wrong terminology for a commercial environment.

Understood. It's just that the PR model only encourages that code review to happen at the very end of the process, when the submitter may have been polishing their work, testing it, and refining it for several days. It would be more efficient for it to occur periodically throughout development, rather than at the very end.

Re: Maintaining code quality when nobody cares

#74

Post by aalleavitch »

Kesty wrote: post #69
aalleavitch wrote: post #65

Earlier quoted context omitted.

Unfortunately there are business reasons why freezing the code is impossible. We’re ecommerce and working on a timeline dictated by consumer behavior. So if we need a promo tomorrow it’s going live or else we’re not making budget. I kind of assume this is how we got into this state to begin with.

And unfortunately nothing will change because what you want to do is better in every single way, but their way of doing thing is better in the only one that actually counts: It's faster and cheaper.

My assumption is that I will never clean up this entire codebase. Rather, I’m looking for the best way to triage the situation: what are the things I can/should try to fix first?

Re: Maintaining code quality when nobody cares

#75

Post by zAy0LfpBZLC8mAC »

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 think it's a result of an open source tool (GitHub) bringing bits of culture along with it.

Erm ... GitHub is entirely proprietary!?

Re: Maintaining code quality when nobody cares

#78

Post by shadowmint »

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

Funny how no one has any meaningful advice, just some snark about those dang young developers. Get off my lawn!

That line wasn't the important part of this post. This one was:

> You should also have a global self-development plan. If you can’t put it into practice under the scope of the project, you should spend your free time on it.

Damn straight.

If you work somewhere with tight deadlines and rubbish code quality, and you're just sucking it up and writing rubbish code, you're part of the problem.

You should always have a plan about how to become a better more effective developer where ever you end up working. Sometimes that means plan to spend 10 minutes a day talking to your project manager. Maybe review code the last 1/2 hour of the day. Maybe make some internal tools to help automate your job.

Don't just sit there and be miserable; if your job/company sucks and you can't find a way to change it, at the very least make it a stepping stone to something better.

Some idle advice from my experiences working in places which sucked:

- If you write code, it should be good code. Even if other code is bad, that's no excuse to stop caring.

- ...but, you dont need to refactor that. Just do what you have to do, and make it as good as it can be under the circumstances. Don't break other things when you make things cleaner and better; that makes PMs think that 'good code' = 'break features'. Disaster.

- If you ship rubbish to 'come back and fix later', you'll never come back and fix it.

- Don't just comment out code and replace it a quick fix. Don't [Ignore] failing tests. If code is going away, take responsibility of actually delete it.

- Don't leave 'TODOs' in your code; either do it, or don't. No one is ever going come back and do your TODO. Not even you. That's what issue trackers are for.

- Some developers don't like running with 'trainer wheels' or 'guard rails' as they refer to unit tests. Ignore these people. Always write tests. The worse the place you work is, the more desperately you need those tests.

- Project managers (unless utterly incompetent) don't care about deliverables per se; they care about managing expectations. Estimate. Review your estimates. Try to deliver on your estimates.

- Don't work overtime unless it'll actually make a tangible difference for a specific deadline. :)

Re: Maintaining code quality when nobody cares

#79

Post by hawski »

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

Lowest hanging fruit should be just an in-place edit that would be automatically retested and that a reviewee can easily take as a patch and check himself. Instead of the back and forth bullshit.

It's a bit funny that placing a red herring comment that anyone can safely comment on makes the workflow faster. It's like this story about an artist who would place something ridiculous so when the time comes the CEO would just say: "It's good, just remove the thing".

Re: Maintaining code quality when nobody cares

#80

Post by maxxxxx »

crdoconnor wrote: post #2

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…

In general I agree with your points. But you seem to have some gripes with "senior" engineers. I think if you left that out your points would be better. In the end it comes down to management not understanding the work and rewarding unproductive behavior. This has nothing to do with "junior" or "senior."
Post reply on HN