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

121–130 of 245 posts

Re: Maintaining code quality when nobody cares

#121

Post by jacquesm »

jimmy1 wrote: post #118
eitland wrote: post #71

Earlier quoted context omitted.

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

Oh I know, that's why I am rebelling! I think words mean very specific things. I know it may seem like unproductive nitpicking, but in my experience the hundreds of discussions I have witnessed and been a part of myself in discussing legacy systems, bringing the pejorative version of the term to the table usually hinders the discussion more than anything, and it is this attitude that greatly contributes to the "softw…

I've worked on old but very well maintained code that could easily go another two decades or more. Probably the original writers have long departed this world. But what they put together was put together with either incredible forethought or impeccably kept up-to-date. It was hard to tell which because this stuff was built before the age of version control, which gives you a bit of an idea how old it was. I would consider that 'mature' code, but not necessarily legacy.

Legacy code to me is code that has become hard or even impossible to maintain. Code that people avoid working on, not because it works, but because they are afraid of it.

Sure there are still lessons to be learned from such code, and you will learn those lessons the hard way if you have the temerity to mess with it. But every now and then someone is tasked with fixing a bug or adding a feature that can no longer be avoided and the send-offs are comparable to talking for the last time to people that are about to descend into a mine or something to that effect. Everybody knows there is a good chance we won't be seeing them again for the near future, if the axe of demotivation doesn't cull them from our ranks.

Re: Maintaining code quality when nobody cares

#122

Post by Bjartr »

tboyd47 wrote: post #68
xstartup wrote: post #64

Earlier quoted context omitted.

What do you mean by throw away? The submitter can always make the requested changes. And if the pull requests are not even relevant then it's entirely a different issue.

Meaning the submitter just spent one week writing code that will have to be written over again. If they had requested feedback informally before the PR, they would have written the code correctly the first time.

Having a PR workflow in place doesn't (or at least shouldn't) stop that person from seeking out that informal feedback earlier. To me it seems like what you're really looking for is pair programming, not pre-completion reviews.

Re: Maintaining code quality when nobody cares

#123

Post by l_t »

maxxxxx wrote: post #80
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."

While I haven't personally worked at such a company, I've observed some "toxic" workplaces and found that typically it is, in fact, the senior staff who are the biggest part of the problem.

Only certain types of people achieve seniority in a toxic organization, and they are typically those who (deliberately or incidentally) benefit from the culture that everyone else hates. They build a clique and try to build influence while the new hires -- who actually care about doing things well -- turn over every 3 months.

This is all anecdotal, of course, but I do think that in an engineering-hostile organization, the senior staff should typically take the brunt of the blame (just as in a successful organization they would take the lion's share of the credit).

Re: Maintaining code quality when nobody cares

#124

Post by icebraining »

crdoconnor wrote: post #87
lloeki wrote: post #28

Earlier quoted context omitted.

We did that (rubocop). Lots of fluff, a dozen or three minor to medium issues, and a couple of downright critical ones that slipped through production cracks out of sheer luck. Not even counting the last ones, the holistic effect of having a code base normalized is unmeasurable (i.e == through the roof), because suddenly moving from one part of the code to another is consistent enough that it removes a mental barrier…

IMO there are two features which linting tools need before I can start treating them as serious "necessities" on a code base rather than "nice to haves". lint [cosmetic | medium | serious] - you must select one to run the tool, and the rule defaults must be sensible. No "100 character line length" in 'medium'. That's strictly cosmetic. Serious is for initialized and unused variables and the like - things which you mi…

pylint has different levels you can select (convention, refactor, warning, error), not sure if it's a common feature.

For the second, see git-lint: https://github.com/sk-/git-lint

Re: Maintaining code quality when nobody cares

#125

Post by hindsightbias »

trevyn wrote: post #104

I’ve often wondered about a twisted form of asynchronous “pair” programming: One person codes quickly, creating mediocre code that achieves the goals, the other person cleans the code up and modularizes it. I’m drawn to this because they are two different mindsets that achieve somewhat conflicting goals, and the tasks can be separated with minimal communication overhead. Thoughts?

There used to be a time where every new coder spent a couple of years learning/maintaining their elders' code - fixing bugs, porting, optimizing, learning about how the environment(s) integrated. The concept of journeyman in sw was a thing, and mgmt/team expectations from the youts was appropriately gated.

Now it's different (outside of HW orgs), but as I look out a decade or so, I'd rather have a part-time retirement job "cleaning up" interesting projects than travel/consulting.

Re: Maintaining code quality when nobody cares

#126

Post by Pica_soO »

jrochkind1 wrote: post #21
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.

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…

Your definition of fighting for a better organisation, boils down to replace people who are apt at nothing but political games with people who are apt with engineering knowledge.

You cant do that, unless you have a little island of sanity at the top, giving you a lifeline and air-support. Sorry, i for once m not good at office version of the game of thrones.

Re: Maintaining code quality when nobody cares

#127

Post by justin_oaks »

logfromblammo wrote: post #120

You build version 1 to throw away, version 2 to be upgraded, and version 3 to be maintained. If you never get to version 3, you never get the opportunity to worry about code quality.

Every company I've worked at will ship version 1 to production and proceed to build on top of version 1 forever. Of course, by version 1 I mean "the proof of concept I showed someone else".

Re: Maintaining code quality when nobody cares

#128

Post by pavel_lishin »

Kesty wrote: post #67
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…

Welcome to code development in the real world 101. You either go insane, give up and take up beekeeping, start your own company or finally decide to not give a shit anymore and start hacking the same way as everybody else because in the end your are not sending astronauts to Mars, and it works "most of the time" is good enough for the clients and the price and time they are willing to pay.

> take up beekeeping

I thought the idea was to have less bugs to worry about...

Re: Maintaining code quality when nobody cares

#129

Post by crdoconnor »

maxxxxx wrote: post #80
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."

It's not seniority per se (I count as senior), it's people with long tenure. If, as a developer, you've had a long tenure in an organization with bad code that's usually a bad sign.
Post reply on HN