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

61–70 of 85 posts

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

#61

Post by themodelplumber »

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.

This weakness in sales-driven organizations applies to other types of employees, too. I used to be a graphic designer for one such organization, and it was next to impossible to create marketing collateral based on design standards; they'd rather buy it in a template kit from an office supply store than wait for a better plan to unfold. I later watched as they completely missed a huge opportunity to go upmarket with the proprietary hardware technology that the product staff developed. They were so obsessed with what was right in front of them that they became embroiled in tactics without strategy, and only the amazing breadth and depth of the market allowed them to continue making a profit without punishing them too severely.

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

#62

Post by paulhauggis »

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 .

If there is an emergency situation where I need to apply a hack, of course. But, I always go back and take the time to fix it with an engineered, long-term, solution.

I also don't over promise features in an un-realistic amount of time.

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

#63

Post by elros »

s73v3r wrote: post #54
wellpast wrote: post #22

Earlier quoted context omitted.

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

That statement makes no sense. It's not like anyone ever has to make a choice between making sound decisions while coding and making sane commits and commit message.

Well, yes, but it's true :-D

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

#65

Post by omouse »

sanderjd wrote: post #48
sbov wrote: post #12

Earlier quoted context omitted.

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"?

It's an issue when dealing with management or clients. They can see long commits as a problem with someone with too much time on their hands.

The whole point of a version control system is that it contains everything related to the code. On lots of web dev and game projects you also commit the finalized assets (the generated javascript from coffeescript, the compressed 3d textures, etc. etc.)

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

#66

Post by mikekchar »

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…

If you write code that solves a people problem and allows your project to move forward, no matter how stinky that code is, that code is "good code".

By nature, we programmers often judge our code on its technical merits. But a stinky piece of crap that I might write that shows me clearly what I need to build, or demonstrates the techniques that are required, or shows that something isn't going to work early, etc can have immense value.

Writing stinky code is a tool that every programmer can use. The trick is to know when you should use it and when you should not. If done properly, you can solve some intractable problems dealing with requirements gathering, design, or even political problems. When used improperly it can have exactly the opposite effect -- it pushes requirements gathering back, or defers important design decisions until it is too late, or creates conflict within the team.

I know some people in the industry who are pretty good at this, but I know of nobody who is a master at it. Not only do you need to be good at it personally, you need to be able to influence the team to coordinate their work in a way that is not destructive. This requires you to have impeccable taste, amazing technical ability and sublime communication skills. It is a skill that I wish more programmers would value and work towards.

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

#67

Post by JohnBooty »

wellpast wrote: post #22
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'll take a sound codebase and zero commit messages over a poorly structured codebase any day.

This choice makes no sense but.... hmm, really? I think I'd rather have good commit messages that explain the "whys" that went into the code.

Code typically isn't rocket science. It's the human knowledge that goes into it that's irreplacable.

Example 1: OK, you're using a third-party CSV parser instead of the one built into the standard library. Why? If your code is crap but well-documented, I can read what you were thinking: "Using non-standard CSV parser because the standard one chokes on files bigger than 2gb" At that point I can refactor your code, or perhaps see that this issue has been fixed in a newer version of the standard library. Or maybe I realize that you confused gigabits and gigabytes and you made a bad choice in the first place, and I realize I can safely remove this dependency. But if your code is tight but undocumented... I would have no idea why this third-party library is being used unless I do some painful trial-and-error that still might not definitively answer the why.

Example 2: You inherit Mary's code. It calculates commissions for our salespeople. The code is sloppy and convoluted, because the sales guys change the commission formulas every month... and these changes have been happening for over ten years, often on very short notice, often contradicting basic assumptions made when the software was originally architected. But Mary documented every change. Which is good, because the fucking sales guys sure don't. Her code is literally the company's only coherent record in the entire company of the commission process. Remove her comments and commit messages, and none of the code would make sense, even if it was tightened up into a sounder codebase of seven modules with 300 LoC each instead of ten modules with 500 LoC each.

So yeah. Totally fictional choice but I'll take documentation every time. Code is just code, I can fix it.

(Both those examples are fictional, but I've been coding professionally for nearly twenty years and I've seen variations of them countless times...)

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

#68

Post by munificent »

"The project was a second attempt to overhaul this complex Module. A first attempt was made between 2010 and 2012 but was abandoned after the fully integrated software did not work. Because this project was a second attempt, many specifications and design documents could be reused. Accordingly, the development has essentially followed a waterfall process, as few problems were expected the second time around."

I love the sheer insanity of this.

1. Write up a plan.

2. Execute the plan.

3. Total project failure. Abandon it.

4. Decide to try again.

5. "It will be easy this time! We've got an existing plan we can use!"

It's like using a treasure map, not finding any treasure, and now thinking it will be even easier to find the treasure now since you already have a map!

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

#69

Post by nandemo »

mikekchar wrote: post #66
dheera wrote: post #25

Earlier quoted context omitted.

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…

If you write code that solves a people problem and allows your project to move forward, no matter how stinky that code is, that code is "good code". By nature, we programmers often judge our code on its technical merits. But a stinky piece of crap that I might write that shows me clearly what I need to build, or demonstrates the techniques that are required, or shows that something isn't going to work early, etc can…

If the code is stinky, it's bad code. It can still be have business value, which is why somebody coined the term "technical debt".

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

#70

Post by dbarlett »

amyjess wrote: post #47
pc86 wrote: post #32

Earlier quoted context omitted.

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

GitHub [1] and Bitbucket [2] do that.

[1] https://help.github.com/articles/closing-issues-via-commit-m...

[2] https://confluence.atlassian.com/display/BITBUCKET/Resolve+i...

Post reply on HN