Why Good Developers Write Bad Code: An Observational Case Study [pdf] • Hacker News Board

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

#51

Post by DougWebb » Mon, May 18, 2015, 9:36 PM UTC

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'm looking at a commit message from one of my clients today, which is just "Not, new bins, cant stop bins" and a check-in of several hundred dlls generated as build artifacts. Six days later another developer at the client checked-in a commit that removed all of the dlls, with the message "remove BIN folder".

Some other examples: "Fixes to make work", "Left Over", and their most common message " ".

They're nice guys to work with, but their VC habits are awful.

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

#52

Post by s73v3r » Mon, May 18, 2015, 9:37 PM UTC

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 .

Bullshit. Most of the time the corner cutting is done solely because shithead sales drones make promises without consulting engineering in the slightest. They get a huge commission for getting the sale and go home at the end of the day. We have to put in more late nights to cover for their asses, and we barely get anything for a raise because of that one time we weren't able to meet sales physically impossible promise.

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

#53

Post by s73v3r » Mon, May 18, 2015, 9:37 PM UTC

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 .

Bullshit. Most of the time the corner cutting is done solely because shithead sales drones make promises without consulting engineering in the slightest. They get a huge commission for getting the sale and go home at the end of the day. We have to put in more late nights to cover for their asses, and we barely get anything for a raise because of that one time we weren't able to meet sales physically impossible promise.

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

#54

Post by s73v3r » Mon, May 18, 2015, 9:40 PM UTC

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.

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.

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

#55

Post by crpatino » Mon, May 18, 2015, 9:40 PM UTC

trhway wrote: post #45

your bad code is somebody else's good code.

I'd put it rather like... for any reasonable definition of "good code" and a sample that highlights the characteristic features of such good code, you will find a competent, intelligent developer that will consider it bad.

Which is more or less the same thing, except that IMHO it does not suggest that every bad code shall be "good" for someone. There's such thing as code that is universally considered as awful (but for their creators, maybe).

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

#56

Post by angersock » Mon, May 18, 2015, 9:43 PM UTC

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 .

It depends, right?

It's right to the biz side of the house, because they have no idea what the costs of those cut corners are. They just know that they asked for shiny feature X, and then that shiny feature X was delivered, albeit with a complaint that the codebase was now Y harder to work on.

Rinse and repeat, and their interface is still "Oh, well, if I ask, the engineers will make it happen".

As this goes on, though, the engineers incur costs and suffering in order to keep delivering. And for any developer worth their salt, there is a very real cost--I almost want to say psychic and emotional trauma--associated with working on bad code.

And these engineers? Odds are, they have no big stake in whether or not the feature works. They're paid (badly) the same way either way, and don't get any benefit whether or not the new feature works.

So, they'll just leave when the continual cost of dealing with a shitty codebase outweighs the benefits of staying at that company. And they'll probably be rewarded with more money for switching!

The incentives are all wrong, and then one day your sales folks realize that any request suddenly takes waaay longer than is acceptable.

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

#57

Post by ploxiln » Mon, May 18, 2015, 9:45 PM UTC

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.

So, there's no such thing as good quality code that saves time in the long run? So we should just give up and hire some cheap overseas contractors because the result will be the same?

To anyone except an MBA running a software project for the first or second time, that's pretty obviously not true. (Some people, when they realize this, do "additional process will be mandated until quality improves".)

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

#58

Post by GoodIntentions » Mon, May 18, 2015, 9:47 PM UTC

DougWebb wrote: post #51

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'm looking at a commit message from one of my clients today, which is just "Not, new bins, cant stop bins" and a check-in of several hundred dlls generated as build artifacts. Six days later another developer at the client checked-in a commit that removed all of the dlls, with the message "remove BIN folder". Some other examples: "Fixes to make work", "Left Over", and their most common message " ". They're nice guys…

I have to admit, I've made number of commits with "." as the message.

No excuse, beyond it usually being a minor change well documented in the code ( I always write comments ) and me being utterly buried under work... You know, start the day with 20 things to do, crack off 4 of them and have 23 things in queue at the end of your day.

The "." was sort of a placeholder for "Fuck This, I'm ready to quit." ( and I did eventually )

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

#59

Post by kremlin » Mon, May 18, 2015, 9:51 PM UTC

bryondowd wrote: post #33

frikk wrote: post #28

Earlier quoted context omitted.

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

Sounds like he lost the local repo, and only the actual final state of the files was backed up. Thus, a single new commit representing everything at once.

yes, that's right. When I got rid of my computer, I didn't save the folder containing the repo; all the commits were lost.

I was able to retrieve the full final content from the place where it was being uploaded to, but that didn't have any git-related files.

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

#60

Post by amag » Mon, May 18, 2015, 9:53 PM UTC

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 all depends of course of the definition of "cutting corners". Sometimes one person's "cutting corners" is another person's "striving for excellence" and sometimes it's "run project into oblivion".

All too often the short-sighted "quickest" way forward is through copy-paste some code that does something remotely similar and massage it into giving the desired output. Sometimes this is necessary, but a lot of times it is not. And every time it leads to technical debt. I've worked on a lot of code bases like this: "Copy file x, rename copy, add copy to project file, rename global names, massage into y, rinse repeat". And then you find a bug in x.

Developers are typically too far removed from customers to ever know, but often the customer is just using time as a bargaining chip. Everybody wants all their needs filled right this instance but most people are reasonable enough to know that the universe doesn't work that way. You just need to gently remind them of it and they will respect you all the more for it, at least if you then deliver quality on time.

Of course this is harder with customers who believe they know a thing or two about development. In their mind it's just change the output of x, but what they don't know is that because you cut corners in the past, you'll need to change the output in y, z, x2, x3, y2, z3 and zz as well...