Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Good Developers Write Bad Code: An Observational Case Study [pdf]

upedu.org

Post reply on HN
Print view View original

21–30 of 85 posts

Re: Why Good Developers Write Bad Code: An Observational Case Study [pdf]

#21

Post by mpdehaan2 »

Offhand and IMHO, some possibles can be:

  - fear or lack of understanding of a legacy codebase
  - fear or lack of understanding of a 3rd party component
  - time pressure
  - too many edge cases to handle
  - intra-team communication issues or stylistic differences
  - lack of domain experience to understand those edge cases
  - lack of time to build the correct design, or rebuild a design if it won't fit
  - project management pressure against big-design-up-front and to "start now" when making something more organized is required
  - unclear requirements
  - not interested in work or company anymore
  - lack of use cases representing all possible usage scenarios
  - it's actually not their code that was bad, but they are coupled to bad systems that are themselves bad/leaky/error-prone

Re: Why Good Developers Write Bad Code: An Observational Case Study [pdf]

#22

Post by wellpast »

tomswartz07 wrote: post #8
hinkley wrote: post #5

Earlier quoted context omitted.

I get really crabby about bad commit messages because on some projects, the commit history is the only 'Why' you ever get. Scratch that, on MOST projects that's the case.

There's nothing worse than a project full of bad commit messages. There was one project I saw that had a two line commit message, and there were 29,000 changed lines across 44 files. Who does that?

I'll take a sound codebase and zero commit messages over a poorly structured codebase any day.

Re: Why Good Developers Write Bad Code: An Observational Case Study [pdf]

#23

Post by derefr »

tomswartz07 wrote: post #16
pacaro wrote: post #15

Earlier quoted context omitted.

Guilty as charged. Or maybe 'nolo contendere'. I just dropped 5kloc, 6 weeks work, into a repo with the message "Initial commit" I'm currently working on the changes that will actually document what is otherwise a walk of code. The road to hell is paved with good intentions.

I could see that. Initial imports and all that. However, my example was a project that was around for about 3 years at that point, and it was basically just labelled: "Upgrade to version 2.0". Face → Palm

I've made that commit before. It was actually an initial import of a from-scratch rewrite that happened to have utility libraries and such in common. Delete everything, drop in the new files you've been working on elsewhere, make that a commit. Not everything changes, because some things are the same by coincidence. Otherwise, it's just a discontinuity.

Re: Why Good Developers Write Bad Code: An Observational Case Study [pdf]

#24

Post by hinkley »

x3n0ph3n3 wrote: post #13
tomswartz07 wrote: post #8

Earlier quoted context omitted.

There's nothing worse than a project full of bad commit messages. There was one project I saw that had a two line commit message, and there were 29,000 changed lines across 44 files. Who does that?

fixed indentation updated to pass new code linter

That's still a why. An irritating one, sure, but it at least tells me to look at the previous commit to find the real 'why'.

Re: Why Good Developers Write Bad Code: An Observational Case Study [pdf]

#25

Post by dheera »

PaulRobinson wrote: post #3

TL;DR key recommendations: - Once a project is completed, the team must ensure that the “What” and “Why” of each software item are properly documented. - In the cases of parallel development of inter-dependent software modules set up a negotiation table to solve conflict between the development teams. - Make sure that the development team is aware of the CMMI-ACQ or ISO12207 processes for negotiating with third parti…

I think there are a lot of conflicting ideas at play here. As a coder, yes I can write good code. But however, everyone I know in the valley tells me "just shut up and launch, it doesn't have to be good. You should have launched yesterday, that's what they would have told you at YC". This advice have a lot of truth to it, because you need to get feedback, validate your project, and perhaps have the first-to-market advantage in the highly competitive world of technology today, with investors and customers hounding you on both sides. However, this hasty, rushed culture necessarily will result in a lot of poorly-written code being deployed (followed by a lot of rewrites), even by decent coders, because they simply aren't given the time and runway.

Re: Why Good Developers Write Bad Code: An Observational Case Study [pdf]

#27

Post by kremlin »

tomswartz07 wrote: post #8
hinkley wrote: post #5

Earlier quoted context omitted.

I get really crabby about bad commit messages because on some projects, the commit history is the only 'Why' you ever get. Scratch that, on MOST projects that's the case.

There's nothing worse than a project full of bad commit messages. There was one project I saw that had a two line commit message, and there were 29,000 changed lines across 44 files. Who does that?

I had a local git repo with a month's worth of commits. I hadn't pushed any of them so they were all _just_ local (though the head was constantly being uploaded to an online store).

I got a new computer and when I was getting rid of my old one, it didn't occur to me to push all the commits or save the git repo. So, my next commit consisted of all the changes for that entire month.

Re: Why Good Developers Write Bad Code: An Observational Case Study [pdf]

#28

Post by frikk »

kremlin wrote: post #27
tomswartz07 wrote: post #8

Earlier quoted context omitted.

There's nothing worse than a project full of bad commit messages. There was one project I saw that had a two line commit message, and there were 29,000 changed lines across 44 files. Who does that?

I had a local git repo with a month's worth of commits. I hadn't pushed any of them so they were all _just_ local (though the head was constantly being uploaded to an online store). I got a new computer and when I was getting rid of my old one, it didn't occur to me to push all the commits or save the git repo. So, my next commit consisted of all the changes for that entire month.

but wouldn't those be represented as individual commits (just happened to be pushed at the same time)?

Re: Why Good Developers Write Bad Code: An Observational Case Study [pdf]

#29

Post by detaro »

PirateDave wrote: post #18
tomswartz07 wrote: post #8

Earlier quoted context omitted.

There's nothing worse than a project full of bad commit messages. There was one project I saw that had a two line commit message, and there were 29,000 changed lines across 44 files. Who does that?

This just reminded me of whatthecommit. IIRC they get these from actual commit messages; if they do, there is no hope. :-) [0] http://whatthecommit.com

https://github.com/janraasch/javascript-commitment/blob/115d...

I'd assume the keys are the commit hashes? Now how to search github for them...

Re: Why Good Developers Write Bad Code: An Observational Case Study [pdf]

#30

Post by bgoerdt »

dheera wrote: post #25
PaulRobinson wrote: post #3

TL;DR key recommendations: - Once a project is completed, the team must ensure that the “What” and “Why” of each software item are properly documented. - In the cases of parallel development of inter-dependent software modules set up a negotiation table to solve conflict between the development teams. - Make sure that the development team is aware of the CMMI-ACQ or ISO12207 processes for negotiating with third parti…

I think there are a lot of conflicting ideas at play here. As a coder, yes I can write good code. But however, everyone I know in the valley tells me "just shut up and launch, it doesn't have to be good. You should have launched yesterday, that's what they would have told you at YC". This advice have a lot of truth to it, because you need to get feedback, validate your project, and perhaps have the first-to-market ad…

The situation is very different when creating software for internal use in large corporations, which I think was the case with this study. With a startup, launching early can get you the advantages you mentioned, and your code quality does not necessarily have to be high because you generally will not have many users at the start. Large internal software must be highly functional and performant from the first deployment because it will immediately be used by the whole company and will often affect revenue streams. This allows low quality to have a huge impact from day 1.
Post reply on HN