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

41–50 of 85 posts

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

#41

Post by arenaninja »

fragsworth wrote: post #36
paulhauggis wrote: post #31

I had to write bad code because sales and management usually dictate the timeline of the project. As an example: sales promises new customer feature X in one month and we will lose money unless it's implemented. My choice is to either: 1) Complete it the right way in double the time or 2) use hacks and cut corners to get it done on time. Since non-technical people just see the output and not what's going on underneat…

> I hated being forced to do this so many times in my career, I started my own company. It depends a lot on what your company is doing, but for the most part, you'll probably discover that cutting corners to save your short-term time is often the right thing to do .

This is definitely true in the interest of shipping anything. The problem is when new features are added to the thing that shipped, small refactorings should make it a manageable beast. Instead, you end up chasing bugs across six different files and fixing the entire thing will take a week and a half of your time because it involves moving things out and straightening the screwup that went on for three days before anybody noticed, so they insist you live on with the bug and keep chasing bugs down as they occur

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

#42

Post by mesozoic »

paulhauggis wrote: post #31

I had to write bad code because sales and management usually dictate the timeline of the project. As an example: sales promises new customer feature X in one month and we will lose money unless it's implemented. My choice is to either: 1) Complete it the right way in double the time or 2) use hacks and cut corners to get it done on time. Since non-technical people just see the output and not what's going on underneat…

Observationally this seems why sales driven organizations might have trouble keeping good developers. They force the build up of so much technical debt and never give the time to fix it that the good developers just leave rather than maintain the nightmare of code they've had to write.

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

#43

Post by arohner »

An interesting article, and we need more like it, but I feel the author didn't go far enough in understanding the root causes of complexity.

For example, they cite both schedule/budget pressure, and insufficient docs. The incomplete docs were "thousands" of pages. Does anyone really believe even half the team would read "complete" documentation, that are thousands upon thousands of pages? Would complete docs speed up development time? Would they speed up development time even taking into account the cost of producing and consuming complete docs? Is the size of module truly essential complexity, or is part of the problem that they're building on legacy code?

The author mentions interop with other teams and third party software as a large source of friction. Why are other modules so large and complex that they're maintained by separate teams? Is that essential complexity, or was it caused by previous attempts to patch their way to release? Would the modules be more manageable, and hence, require smaller teams, if they used other practices/languages/tools?

Access to test hardware, and managing the test personnel was another source of friction. What is the cost of buying more test hardware? In previous companies where I've worked, with manual QA depts and under-funded test hardware budgets, doubling the hardware budget would allow halving the QA salary budget (primarily because you don't need to hot-swap equipment several times a day), and shorten test cycles. Is that the case here?

Further, how much manual test is truly necessary, and how much is caused by the developers not writing automated tests?

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

#44

Post by juliangregorian »

silverbax88 wrote: post #38
paulhauggis wrote: post #31

I had to write bad code because sales and management usually dictate the timeline of the project. As an example: sales promises new customer feature X in one month and we will lose money unless it's implemented. My choice is to either: 1) Complete it the right way in double the time or 2) use hacks and cut corners to get it done on time. Since non-technical people just see the output and not what's going on underneat…

I will tell you, as someone in the same position, that even when you get all of the time you need, and you write elegant, beautiful code, in five years that code will probably seem clunky and outdated, and someone will ask you what the heck you were thinking when you wrote it.

After five years, you'll probably ask that of yourself! But if I was really given all the time I preferred, I'd have brought the code current with my ideals.

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

#46

Post by 0xdeadbeefbabe »

mesozoic wrote: post #42
paulhauggis wrote: post #31

I had to write bad code because sales and management usually dictate the timeline of the project. As an example: sales promises new customer feature X in one month and we will lose money unless it's implemented. My choice is to either: 1) Complete it the right way in double the time or 2) use hacks and cut corners to get it done on time. Since non-technical people just see the output and not what's going on underneat…

Observationally this seems why sales driven organizations might have trouble keeping good developers. They force the build up of so much technical debt and never give the time to fix it that the good developers just leave rather than maintain the nightmare of code they've had to write.

Are you implying logic driven companies exist?

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

#47

Post by amyjess »

pc86 wrote: post #32
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?

What was the commit message? "Issue #27" is terrible. Something like (in C#/VS) "Execute CodeMaid against solution" would be perfectly fine.

Depends on how you have things set up. I once worked at a company with SVN/Trac integration. If you put "Refs #27" in a commit message, it would actually add a link to the commit as a comment on the ticket. If you put "Fixes #27", it would do that and close the ticket. Our system was also set up so you had to ref or fix a valid ticket in order to commit.

I miss having a system like that...

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

#48

Post by sanderjd »

sbov wrote: post #12
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.

I'm a fan of whys. Even for yourself. I have code I have to maintain that I wrote 10 years ago. But it can make for long commit messages. Why also includes what alternatives you considered, and why you didn't use those. I also like to have a digital "worksheet" for each change I do, where all my thoughts and research goes. So if all else fails, I can reference that. But no-one else can, so I like to transfer as much…

Is there any scenario under which a long commit message is detrimental, even if "messy"?

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

#49

Post by derwildemomo »

0xdeadbeefbabe wrote: post #46
mesozoic wrote: post #42

Earlier quoted context omitted.

Observationally this seems why sales driven organizations might have trouble keeping good developers. They force the build up of so much technical debt and never give the time to fix it that the good developers just leave rather than maintain the nightmare of code they've had to write.

Are you implying logic driven companies exist?

yes, they do. I'm contracting (in germany, if that's important) and about a third of the companies that hire me have high or very high standards when it comes to avoiding technical debt, adherence to sane development cycles and clean code. So yes, there are those companies.

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

#50

Post by mathattack »

fragsworth wrote: post #36
paulhauggis wrote: post #31

I had to write bad code because sales and management usually dictate the timeline of the project. As an example: sales promises new customer feature X in one month and we will lose money unless it's implemented. My choice is to either: 1) Complete it the right way in double the time or 2) use hacks and cut corners to get it done on time. Since non-technical people just see the output and not what's going on underneat…

> I hated being forced to do this so many times in my career, I started my own company. It depends a lot on what your company is doing, but for the most part, you'll probably discover that cutting corners to save your short-term time is often the right thing to do .

Indeed. Very frequently "getting it out the door" can mean enough money to hire a great developer vs just a good one. There are salespeople whose over-promising causes more harm than good, but it's not black and white.
Post reply on HN