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

111–120 of 245 posts

Re: Maintaining code quality when nobody cares

#111

Post by hinkley »

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?

Eventually you feel like a janitor or a babysitter.

The problem is that the guy making the mess gets credit for things and the guy cleaning it up keeps bad things from happening because of him. If your boss is not just the right type then you will become the bus tribute.

Re: Maintaining code quality when nobody cares

#112

Post by [deleted] »

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?

[deleted]

Re: Maintaining code quality when nobody cares

#113

Post by [deleted] »

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?

[deleted]

Re: Maintaining code quality when nobody cares

#114

Post by ConceptJunkie »

oldandtired wrote: post #5

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…

I absolutely follow these principles, and I often joke that I do everything I can to idiot-proof my code because the next idiot who comes around is usually me.

But unless you get support for this from middle and upper management, you're fighting a losing battle. You can't fix the world from behind the scenes. I know, I've been trying for many years.

My immediate managers have always been supportive of this attitude, but since everyone above them is concerned only with "How fast can we ship this?", and has the attitude, "We care about code quality, unless that means we have to dedicate resources to it." and "We will gladly spent 10 units of next month's or next year's resources to save 1 unit of resources for this week's release."

I understand the pressures of business needs, and sometimes you really do need to ship ASAP and sacrifice features or the insurance of quality of a well-defined piece of your project for revenue's sake. But at some point, constant compromises point to flawed management.

Re: Maintaining code quality when nobody cares

#115

Post by ManlyBread »

I've tried this approach in the past and and it has made me very bitter. Eventually I realized that the company I worked for enforced no accountability for bad code, so I would often open the solution later and found a pile of ugly hacks or other mess. Code reviews? Refactoring? "We don't have time and no one is going to pay for it". Eventually you come to a conclusion that if no one cares then why should you? If any effort on your part is going to be negated by your coworkers anyway then why bother? How do you push back against a corporate culture that has been there for years and no one seemed to have a problem until you came along? Maybe it's possible when you're a senior dev that has control over a project, but as a mid level developer I've never been successful at enforcing any standard - people usually don't care because it would mean additional work and effort on their part and they still get paid the same regardless of the quality of the code.

Re: Maintaining code quality when nobody cares

#116

Post by ConceptJunkie »

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…

You're absolutely right, and my immediate bosses have dedicated themselves to laying down the law that good work requires more time. We live in a culture where there is a lot of technical debt inherited from a culture that used to be much worse than it is now, and I think we've made some progress on the front of not increasing the technical debt, by insisting on the resources to do things right. Now, reducing the technical debt is another matter.

Re: Maintaining code quality when nobody cares

#117

Post by ashelmire »

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…

...wow, this is my organization to a T.

Needless to say, it's time for a move upward and outward.

Re: Maintaining code quality when nobody cares

#118

Post by jimmy1 »

eitland wrote: post #71
jimmy1 wrote: post #22

Earlier quoted context omitted.

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

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 "software is eating the world" problem we soon to experience with everyone recreating the same library every day instead of reusing existing, proven solutions -- talk about unproductive!

"Back in my day", legacy systems were admired! I mean, heck, they were still there because some team(s) were using them every day, more often than not, they were there because they made money.

As one famous software engineer once said, "'Legacy code' often differs from its suggested alternative by actually working and scaling."

NASA was reusing code written from the 70's all the way up to 2011! Surely there is something in this wonderful land of legacy code that is worth saving? Or how about our operating systems? Full of wonderfully working legacy software that might just need a touch of love, rather than the usual thrashing of "how stupid those other devs were" and a total rewrite, which is what usually happens sadly.

In any case, I think another poster may have touched on it, I think we as engineers should try to refrain from flippantly labeling anything that is essentially "old" (where "old" might be 6 months, 2 years, or 10 depending on the organization) as the pejorative form of "legacy software", and just call it what it is -- bad software, some of which may also be legacy to your organization. But the conflation of the two terms is not helpful and adding to the confusion.

Re: Maintaining code quality when nobody cares

#119

Post by ConceptJunkie »

leibnizwasright wrote: post #9
majewsky wrote: post #7

Earlier quoted context omitted.

It's sad that this gets downvoted, because it's the only realistic approach in such a situation (which is also sad).

Yes, I don't see this a problem, normally releases get delayed, if you get more time to develop better, then why not? I always saw testers talking with product owners and managers about one or other developer that was slower but had delivered less defect.

I know that feeling. I'm one of those developers that is slower than a lot, but I also know from long experience that when I deliver something, it's solid. It's not that I don't make mistakes, but that I work in a way that helps to minimize them when I do make them. It takes me longer to get things done than the hotshots, but there will usually be fewer problems and the problems that do exist will usually be much shallower. And unlike a lot of people my work contributes to a net decrease of technical debt.

I'm not saying this to brag, but to emphasize that this is what it takes to do quality work.

Post reply on HN