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

It Takes 6 Days to Change 1 Line of Code

edweissman.com

Post reply on HN
Print view View original

91–100 of 237 posts

Re: It Takes 6 Days to Change 1 Line of Code

#91

Post by phillmv »

fleitz wrote: post #34
lmkg wrote: post #29

Earlier quoted context omitted.

"Changing one line of code took 6 days!" is a pretty common WTF story. It comes up every so often, and we all get a chuckle at the ponderous rate of change in large organizations. However, "Changing one line of code broke everything for 6 days!" is also a common WTF story. As a rule of thumb, you can't avoid both of them, because avoiding one entails the other. I wouldn't fault a company that chooses the first story…

Or you could just hire responsible people and ask them to use their judgement, you don't have to choose one or the other you can instead apply judgement as to whether this is going to screw shit up or not. Honestly, though the best way to handle this situation is with a phone call to the CEO/IT Director getting him to write you an email allowing you to override all the checks to get this in ASAP. Once you're known fo…

Feh.

For starters, "just hire responsible people" can't be applied retroactively. Not to mention that… most people are responsible, or rather, the road to hell is paved with good intentions.

Secondly, it's an incredibly difficult thing to scale. That works great in startups, but by the time you have things like "HR Directors" you're no longer capable of having insight into the rest of the organization.

There is a lot to be said about how bureaucracies are the formalization of common sense, and a lot more to be said being able to scale processes out such that you don't end up in situations where stakeholders have no visibility into the work performed.

I just feel that the answer is more complicated than "hire A players".

Re: It Takes 6 Days to Change 1 Line of Code

#92

Post by MartinCron »

bengl3rt wrote: post #4

Honestly, for code that controls millions of dollars worth of business and could seriously screw over a lot of people if a subtle flaw was introduced, I don't see a problem with doing it this way. Might be overkill for one line of code, but where do you set the threshold? If you say any change longer than four lines is subject to this process, then people will work on trickling in new stuff in increments of four line…

If you say any change longer than four lines is subject to this process, then people will work on trickling in new stuff in increments of four lines at a time

With proper test automation and continuous deployment, trickling new stuff in increments of four lines at a time is the right way to do it.

Re: It Takes 6 Days to Change 1 Line of Code

#93

Post by dools »

I seriously don't see the problem. The author seems to be assuming that taking 6 days to have a change made is objectively bad.

Does the company run? Does it make money? Do the systems work and stuff?

Well, if whatever you're doing now to keep the systems working and the company running and making money obviously works so I'd say it's objectively good.

The experience may feel bad subjectively but how you feel is of trivial importance when compared with the health of the company as a whole.

It's all about risk right? Like if the company wants to spend $50,000 to change 1 line of code, and it's not going under, then that's obviously the right decision. It's just the same as spending millions of dollars per year on insurance and then complaining when the place doesn't burn to the ground.

The "move fast and break things" attitude of Facebook works for Facebook - it's a different company.

Small startups can break whatever the hell they want because they're not making any money yet.

An established company with a functional system that makes money has to take measures to protect it, because that functional system is where all the value is in the company.

Re: It Takes 6 Days to Change 1 Line of Code

#94

Post by ojbyrne »

DougBTX wrote: post #88
badclient wrote: post #82

Earlier quoted context omitted.

And if your workplace environment really doesn't permit that, move on. Doing just that :) It's basically a startup with 10 of us where I am the only in house developer. I've tried many things like asking folks to Skype me instead of walking over to my desk or calling my name. I've gone to great lengths to get em to understand why skyping to get my attention is different than other ways. None of these guidelines reall…

Tim Schafer, of http://www.kickstarter.com/projects/doublefine/double-fine-a... fame, has a note on his door until 11am in the morning saying, don't knock, writing. Could you make progress on projectY if you made a deal to not work on projectX until 11am? To not even open your office door? (FWIW, this is a classic Quality of Service (QoS) algorithm, where traffic on ProjectY is given dedicated bandwidth (2 hours in t…

Door? Who has those anymore? In the interest of collaboration open-plan offices have become the norm, to the detriment of productivity everywhere.

Re: It Takes 6 Days to Change 1 Line of Code

#95

Post by paddy_m »

DougBTX wrote: post #88
badclient wrote: post #82

Earlier quoted context omitted.

And if your workplace environment really doesn't permit that, move on. Doing just that :) It's basically a startup with 10 of us where I am the only in house developer. I've tried many things like asking folks to Skype me instead of walking over to my desk or calling my name. I've gone to great lengths to get em to understand why skyping to get my attention is different than other ways. None of these guidelines reall…

Tim Schafer, of http://www.kickstarter.com/projects/doublefine/double-fine-a... fame, has a note on his door until 11am in the morning saying, don't knock, writing. Could you make progress on projectY if you made a deal to not work on projectX until 11am? To not even open your office door? (FWIW, this is a classic Quality of Service (QoS) algorithm, where traffic on ProjectY is given dedicated bandwidth (2 hours in t…

the key part of that story is that Tim Schafer has a door.

Re: It Takes 6 Days to Change 1 Line of Code

#96

Post by MartinCron »

epochwolf wrote: post #6
serverascode wrote: post #2

This happens waaaaaaay more than anyone will admit.

Is it sad that I think 6 days is pretty fast?

Yes, it's very sad. I get kind of twitchy and nervous if code that I have written doesn't get tested and into production same-day or next day.

Re: It Takes 6 Days to Change 1 Line of Code

#98

Post by vacri »

benjaminwootton wrote: post #47
ww520 wrote: post #24

People don't realize processes, reviews, standards, and audits are there because of painful (costly) incidents and breakdowns in the past. Changing one line of code in the production app is fast and easy. Crashing the system or screwing up the app logic can cause huge disruption to the operation. After every single crisis, managers got together and vowed to never let this happen again, and thus processes and reviews…

I liked this post on the topic - http://37signals.com/svn/archives2/dont_scar_on_the_first_cu...

"embed the learning in the organizational memory as a story instead of a policy"

That memory is hard to maintain with procedural changes in modern times, as employees move around quite frequently.

Re: It Takes 6 Days to Change 1 Line of Code

#99

Post by saraid216 »

VikingCoder wrote: post #30
bengl3rt wrote: post #4

Honestly, for code that controls millions of dollars worth of business and could seriously screw over a lot of people if a subtle flaw was introduced, I don't see a problem with doing it this way. Might be overkill for one line of code, but where do you set the threshold? If you say any change longer than four lines is subject to this process, then people will work on trickling in new stuff in increments of four line…

Did you miss this part: > It [sic] we don't do this right away, we'll have to have a layoff. As a company, it's great to have a process for incremental changes, but you also need to have a process for critical hot-fixes. You're a phone company, and adding a new feature should take months. I get that. You're a phone company, and because of an unforeseen Cinderella problem, 10% of your customers can't make phone calls.…

> As a company, it's great to have a process for incremental changes, but you also need to have a process for critical hot-fixes.

And as soon as you do, everyone thinks that their problem is a good candidate for the critical hot-fix path. At the very least, you now have to sink minutes per day into arguing them down from using it. Worth it? Possibly. But not always.

Re: It Takes 6 Days to Change 1 Line of Code

#100

Post by peacemaker »

It's exactly this situation that made me leave a large company after only 5 weeks. I'd come from a smaller, more agile environment and having to go through multiple layers of process and bullshit just to get the simplest thing done was just too much for me. I know 100% that if I'd have stayed there I would have ended up hating my job and affecting my passion for writing code.

The main situation I remember is a code review of a few lines I'd written kept on being rejected by some of the more process-indoctrinated programmers purely because I didn't use the correct type of verb in the first sentence describing my change! I mean, when that is the shit that matters and not solutions to problems, I'm out.

Post reply on HN