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

31–40 of 237 posts

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

#31

Post by benjaminwootton »

aslakhellesoy wrote: post #22
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…

And more importantly: a complete lack of trust within the organisation.

Agreed. 19 times out of 20 people will do the right thing.

Therefore, process like this unnecessarily slows down the organisation 95% of the time.

Much better to trust people and implement very specific and very carefully designed safety nets such as fast rollbacks.

In most cases, the benefits of just trusting people will massively outway the costs of the occasional slip up.

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

#33

Post by [deleted] »

lmkg wrote: post #29
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…

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

[deleted]

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

#34

Post by fleitz »

lmkg wrote: post #29
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…

"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 for clearing things with hire ups, QA will start being reasonable. You have to keep in mind that most people in QA are type C personalities and will be a stickler for inane rules.

http://www.buzzle.com/articles/type-c-personality.html

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

#36

Post by eridius »

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

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

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

#37

Post by j_baker »

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…

Indeed. But that doesn't mean that you have to like taking 6 days to write one line of code.

That said, 6 days isn't so bad as long as we're talking about the time it takes to write the code and put it into production. It's another thing to take 6 days to put the code into source control.

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

#38

Post by HeyLaughingBoy »

benjaminwootton wrote: post #14
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…

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 written down anywhere." If it's important enough to reject the code, it's important enough to write down.

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

#39

Post by HeyLaughingBoy »

ajross wrote: post #26
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…

Exactly. The point bengl3rt was making, I assume, is that cavalier avoidance of process is a bad thing because it allows mistakes to happen that would be caught. That much is true. But the assumption that's wrong is that all processes avoid mistakes. Clearly they don't. And some of the examples here are just plain cargo cult misapplications of good ideas. The point behind code review is to catch design flaws in new c…

Demand, no, but often it is the best idea.

Having just (as in hours ago) been through the wringer of adding new features to a mass of spaghetti that had not been touched in 10 years, the only way I could maintain my sanity (and have some assurance beyond regression testing) that I wasn't breaking something, was to refactor the existing code and then insert my changes.

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

#40

Post by benjaminwootton »

bobbles wrote: post #28
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…

A few notes on those points: 1) The fields are probably mandatory because so many times routine entries were not filled correctly, and even MORE overhead was required going back and forth between teams to find out all of the details. If there is a way to avoid this overhead, again, how do you stop people abusing it? 2 & 3) Yeah.. bad overhead. 4) A sanity check is ALWAYS a good idea, whether its a fresh intern or the…

I really like to see a pragmatic relationship between Dev and QA where you reach agreement on the best way to build confidence in a change.

QA should absolutely be able to push back on Dev with regards to quality and relevant test cases, but likewise Dev often need to be able to direct the testing and mutually agree on the scope that will get the change signed off adequately.

Post reply on HN