It Takes 6 Days to Change 1 Line of Code • Hacker News Board

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

#11

Post by ojbyrne » Thu, May 17, 2012, 9:50 PM UTC

sp332 wrote: post #10

Why aren't you appealing directly to Philip more often? Give him a list of what you need and he could have what he wants with 3 emails. Also I don't understand what "access" you need to Marge? You can't email her or something? edit: d'oh

I could be wrong, but I think Homer and Marge are servers, not people.

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

#12

Post by jacobr » Thu, May 17, 2012, 9:51 PM UTC

sp332 wrote: post #10

Why aren't you appealing directly to Philip more often? Give him a list of what you need and he could have what he wants with 3 emails. Also I don't understand what "access" you need to Marge? You can't email her or something? edit: d'oh

Homer and Marge are most likely some kind of testing systems.

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

#13

Post by Falling3 » Thu, May 17, 2012, 9:51 PM UTC

sp332 wrote: post #10

Why aren't you appealing directly to Philip more often? Give him a list of what you need and he could have what he wants with 3 emails. Also I don't understand what "access" you need to Marge? You can't email her or something? edit: d'oh

I thought it was pretty obvious that Marge is a computer.

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

#14

Post by benjaminwootton » Thu, May 17, 2012, 9:52 PM UTC

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
  - 'Micro' Code reviews
  - Excessive permissions and security processes internally
  - No pragmatism with regards to testing the change

This kind of stuff is a constant and substantial overhead on getting anything done. You need to look at these processes very critically and be very sure of the benefits in terms of quality before introducing it.

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

#15

Post by gaius » Thu, May 17, 2012, 9:52 PM UTC

Ironically, work to prevent layoffs neatly identified all the people who should be laid off immediately.

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

#16

Post by mangler » Thu, May 17, 2012, 9:54 PM UTC

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.

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

#17

Post by protomyth » Thu, May 17, 2012, 9:56 PM UTC

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?

I've worked places where 6 days would be a miracle. For me, the worst has always been when the database query plan suddenly switched to something with a full table scan (I'm looking at you Sybase) or the always fun full sort merge (nice going Ingres). It always seemed to come down to forcing indexes which tended to get deployed fairly quickly.

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

#18

Post by tcskeptic » Thu, May 17, 2012, 9:57 PM UTC

I understand the advice to quit because of the agonizing process involved, but worse than that for me is the idea that this parameter is hard coded, and even with this change in place that limitation still remains. NO WONDER the change process is so painful, the software design is clearly brain dead. I bet all kinds of unexpected shit happens when changes are rolled out. This is a code smell like a rotting corpse.

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

#19

Post by [deleted] » Thu, May 17, 2012, 9:58 PM UTC

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…

[deleted]

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

#20

Post by webcowboy » Thu, May 17, 2012, 9:58 PM UTC

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…

I'm glad this is being said.

I would add that crappy processes and tools are usually in place because the management/leadership in an organization has made them too brittle. While you don't want to wild-west every "critical" issue, bad spots in a process will naturally highlight themselves over time.

Let your tools and processes constantly evolve instead of blindly subscribing to a methodology, and you'll be in much better shape.