Live data from Hacker News

How terrible code gets written by sane people

chrismm.com

71–80 of 151 posts

Re: How terrible code gets written by sane people

#71
post #21
post #17

Earlier quoted context omitted.

Code should be reviewed, preferably by a different group of people who wrote the code, metrics are only useful for people to manage themselves. Upon review there should be immediate feedback to people who wrote it and if they continue to make the same errors, then you should eventually get rid of the person who wrote it. Making up stupid systems of control to "incentivize" people as a method of management is the stup…

>is the stupidest thing rationalists ever cooked up. Oh, you don't like bonuses then? Unsolicited, forced code review doesn't have much value that I've found, unless your team is fairly junior. Senior guys know what good code looks like, even in a crunch. If you hold forced, unsolicited code reviews with senior developers, you are really just throwing away money and aggravating people. It's just another half thought…

what about if you reverse the incentives...

Product Managers get bonuses related inversely to hours of downtime (caused by bugs).

Engineers get bonuses related to number of features pushed out.

In theory, this would encourage engineers to ship as fast as possible whilst encouraging PMs to ensure quality over quantity wrt feature scope/volume. This way you'd have engineers begging to add features and PMs begging for tests.

What am I missing - how can this be gamed?

Re: How terrible code gets written by sane people

#72
Perhaps the team planned a rewrite long ago and stopped worrying about the quality of their code, which seemed obsolete in the moment it was written. Over the years, however, there was always something more important than the "soon-to-be" rewrite.

Re: How terrible code gets written by sane people

#73
post #51

It feels like people are focusing on bad conditions and unreasonable deadlines, and not the idea that in the real world smart people under execellent conditions do this very, very frequently. I've worked for long periods of time in 3 codebases that were over 2 million loc in my career, all had great conditions, all had very smart people. Those are not huge codebases by any standard, and yet all 3 had people talking a…

> My theory is that all software eventually becomes difficult to maintain and full of warts, regardless of smartness, regardless of conditions.

I've come to a similar (intermediate) conclusion for now. Would certainly fit the general pattern of "all things" in this physical universe.

I think there's also a lot of subtle human psychology at play at all times in this subject. Identifying and ruminating over such "issues" implicitly elevates oneself (to peers, the community, the boss, the client, the family, to self, etc), materializes potential future employ ("this needs a total overhaul ---by me/us, according to this latest/proven/bla paradigm/methodology/platform --- or the project is doomed, I say, doomed"..), satisfies many a engineer's/programmer's inner yearning for learning to do better, inching a bit closer to perfection, lifting the whole field, etc.. our supreme tendency to fool ourselves (about ourselves and the power of one's mental and aux toolkit) on the daily that probably keeps us going so eagerly in this (frankly for mammals somewhat weird) "activity", it all comes together suspiciously neatly when one looks at others' codebases / current conditions with that "damning-professional's glance"! =)

Re: How terrible code gets written by sane people

#74
post #43
post #26

Earlier quoted context omitted.

I sympathize with this, but perhaps it is really more economical to write software like this in your company's case (?)

Maybe. Usually I'm hired to help out later in the project, when the original developers can't handle the ever increasing number of bugs and edge-cases.

This. You get hired, you look at the code, you point out where it sucks, the team hates you, they gripe about you to management...

It's tricky managing developers. They are smart and defensive.

Re: How terrible code gets written by sane people

#75
post #71
post #21

Earlier quoted context omitted.

>is the stupidest thing rationalists ever cooked up. Oh, you don't like bonuses then? Unsolicited, forced code review doesn't have much value that I've found, unless your team is fairly junior. Senior guys know what good code looks like, even in a crunch. If you hold forced, unsolicited code reviews with senior developers, you are really just throwing away money and aggravating people. It's just another half thought…

what about if you reverse the incentives... Product Managers get bonuses related inversely to hours of downtime (caused by bugs). Engineers get bonuses related to number of features pushed out. In theory, this would encourage engineers to ship as fast as possible whilst encouraging PMs to ensure quality over quantity wrt feature scope/volume. This way you'd have engineers begging to add features and PMs begging for t…

The PMs will have an incentive to shift the blame around ("oh it worked fine when we tested it, it must be the fault of the database, not our bug"), while you'll only get "10x" engineers who turn your codebase into a flaming turd that's unmaintainable over the long term.

Re: How terrible code gets written by sane people

#76
post #51

It feels like people are focusing on bad conditions and unreasonable deadlines, and not the idea that in the real world smart people under execellent conditions do this very, very frequently. I've worked for long periods of time in 3 codebases that were over 2 million loc in my career, all had great conditions, all had very smart people. Those are not huge codebases by any standard, and yet all 3 had people talking a…

> My theory is that all software eventually becomes difficult to maintain and full of warts, regardless of smartness, regardless of conditions.

If a code base doesn't change too much in side or original intent then architecture and design (if it was good in the first place and is continued to be followed) will probably keep it fairly maintainable.

In a lot of cases though codebases slowly grow until they become of a size that requires a different architecture or approach to organising the code, especially if the number of collaborators increases too. It's quite a hard thing to spot and then address while that codebase is still quite active.

Rewrites are tempting to be able to apply that architectural change but often you can be quite bound by the implementation specific behaviour of the original system.

It might be interesting to look how the linux kernel has changed internally as it moved from a single person project to what it has become today.

Re: How terrible code gets written by sane people

#77
post #71
post #21

Earlier quoted context omitted.

>is the stupidest thing rationalists ever cooked up. Oh, you don't like bonuses then? Unsolicited, forced code review doesn't have much value that I've found, unless your team is fairly junior. Senior guys know what good code looks like, even in a crunch. If you hold forced, unsolicited code reviews with senior developers, you are really just throwing away money and aggravating people. It's just another half thought…

what about if you reverse the incentives... Product Managers get bonuses related inversely to hours of downtime (caused by bugs). Engineers get bonuses related to number of features pushed out. In theory, this would encourage engineers to ship as fast as possible whilst encouraging PMs to ensure quality over quantity wrt feature scope/volume. This way you'd have engineers begging to add features and PMs begging for t…

What you cause is stress and tension between the two groups. They start to hate each other and blame each other. "That's not a bug - that feature was never in the spec"

Re: How terrible code gets written by sane people

#78
post #51

It feels like people are focusing on bad conditions and unreasonable deadlines, and not the idea that in the real world smart people under execellent conditions do this very, very frequently. I've worked for long periods of time in 3 codebases that were over 2 million loc in my career, all had great conditions, all had very smart people. Those are not huge codebases by any standard, and yet all 3 had people talking a…

I've worked on teams that kept the code base clean for years.

We did it by focusing hard on just that. Ruthless refactoring, zero bug tolerance, and no deadlines are maybe the biggest factors.

Re: How terrible code gets written by sane people

#79
post #50
post #35

Earlier quoted context omitted.

A reviewer soon understands that senior devs are producing good code and stops investing time on reviewing their code. If they are doing their job properly. But again it comes down to internal motivation and self management on their part.

Yes, sorry I should have been more explicit. Initial reviews have value (is this guy full of beans or does he know what he's doing), but constant reviews of senior developer code do not. If you've hired anyone you have to constantly do reviews for, you've probably hired the wrong person. I mean they should get what you are looking for after a month or two.

I know exactly zero developers senior enough to have gotten over writing bugs. I know I've written bugs that happened to pass all my tests only to blow up in somebody else's face, sometimes after surviving years of production use.

Code review would've at least had a chance to catch them early—so long as you treat it as critical analysis of program logic and not just a screen for generic goodness.

IMO if your code reviews are glorified manual style checking, you're doing it wrong.

Re: How terrible code gets written by sane people

#80
post #38

Honestly, I think the best developers are not the ones that write beautiful code and put quality above everything else. The best ones are the ones that can push out a solution given too little time and given a (maybe self inflicted) bad code base. Because that's real life, and not the pony farm. Money trumps everything else in capitalism. Getting money means paying your bills today. And even more so than skill, quali…

> Money trumps everything else in capitalism. Getting money means paying your bills today. And even more so than skill, quality and code getting money requires kowtowing and overpromising to someone who currently has money. That has little to do with what makes development and a lot more to do with capitalism, business, and markets. What this really means is that current business environments don't necessarily value…

All you say is true. And yet, if you don't get paid for doing open source you're probably spending more time of the week worrying about money than good code.

What do you think about the argument that once you have handled the money topic well enough, then you can worry about quality. I.e. first you make a basket business that earns enough money so you don't ever have to work again. Then you try to improve the process and result of making baskets as a hobby.

Post reply on HN