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

41–50 of 237 posts

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

#41

Post by VikingCoder »

eridius wrote: post #36
VikingCoder wrote: post #30

Earlier quoted context omitted.

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

What's a Cinderella problem? I'm assuming it's a reference to the midnight deadline.

The code behaves differently after some event happens.

Midnight. Y2K. Daylight Savings Time change. Leap Day. Congress changes when Daylight Savings Time happens and one component in the system didn't know about it. Year 2038 problem.

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

#42

Post by benjaminwootton »

HeyLaughingBoy wrote: post #38
benjaminwootton wrote: post #14

Earlier quoted context omitted.

Reliability and quality are obviously important, but you have to question whether all these steps are actually helping you to achieve that. All of these items in the story add overhead and reduce agility, but potentially do very little to improve quality: - Mandatory paper trail via fields on the issue tracker - The need for documented internal sign offs - Standards and policies with no clear reason for the existence…

- Code reviews I have to take issue with this one. Code (and Requirements, and Design) reviews, when done properly probably have the greatest impact in improving product quality. No, I don't have time to look up the SEI research on the subject, but it has been consistently shown to be true. Part of the problem I had with the article was that Shirley was rejecting code for non-specific reasons. You can't say "it's not…

I like code reviews for higher level concerns - new class hierarchies, big pieces of refactoring, new areas of functionality etc.

However, I don't see as much value in reviewing low level changes such as one liners or odd bug fixes.

Making code reviews mandatory is too much overhead and too inflexible for me.

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

#43

Post by aninteger »

mangler wrote: post #16

No, don't quit! Embrace! That's 14 hours (if I remember correctly) you could have spent working on your own projects instead of being pissed off on HN. The world is full of this, and it's well accepted and nobody questions it - make the most of it.

I agree with you here. That's a ton of free time. Unfortunately Ed probably posts one disgruntled story each month. I predict he'll post one next month too. He wont quit, he'll just complain on Hacker News.

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

#44

Post by zackzackzack »

mangler wrote: post #16

No, don't quit! Embrace! That's 14 hours (if I remember correctly) you could have spent working on your own projects instead of being pissed off on HN. The world is full of this, and it's well accepted and nobody questions it - make the most of it.

They wouldn't be his projects. They would be the company's.

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

#45

Post by akg »

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…

Agreed. I think the main problem in this story however is the the red-tape between people and not so much the process itself.

Ask Homer, well Homer is not in so ask Marge, well I don't have access to Marge. Delays like this that come from artificial communication barriers can be easily avoided if they worked on improving communication throughout the organization. It would probably have saved them 1-2 days, if not more.

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

#46

Post by twelvechairs »

As good a 'system' as you might have, it is still no match for having a middle manager with a clue (and some freedom to move within the system)...

Sure - this should have still been tested (and thoroughly!), but putting this 'on the queue' when it needs doing now? Making the programmer deal with other issues (rename the variable) while doing it? Not making sure that a testing machine was available? No....

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

#47

Post by benjaminwootton »

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

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

#48

Post by rmc »

fierarul wrote: post #23

Heh, not the same corporate snafu, but my most expensive work was done to change 1 char. Spent about 3 weeks with a new codebase to find that one number had to be increased. Funny thing is, there was a comment there and somebody had increased it before when they had a similar problem.

Time to change the character: 10 seconds

Time to find out what charater to change: 3 weeks

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

#50

Post by Dove »

That "legacy code must be brought up to current standards whenever it's touched" policy doesn't seem very wise. I'm all for practical refactoring, but it's a major decision to be treated with care when it comes to legacy code. You don't always want to invite it. I certainly wouldn't want to enforce it.

I mean, it's one thing when your oldest legacy code is two years old, and it's all one program. It's something else entirely when it's, for example, written in Fortran and running on hardware you can't buy anymore. Sometimes you don't want to rock the boat any more than you absolutely have to.

Post reply on HN