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

51–60 of 237 posts

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

#51

Post by boyter »

I just went through the same thing. Except I was smart (or so I thought) and had what I needed changed in a config file.

PHB decided that it still counted as a "code" change because someone needed to log onto the box and change the config. Literally it was removing 3 characters from it. The only reason I even had it in the config was to avoid it being a code change to begin with. I argued back that in the time I would take to get through the whole process I could write a screen to do the same thing.

PHB said that would be fine as from that point on its a config not a code change. So off through the whole process, where I present the change to people who don't care, or understand the change and ask for them to approve it. I get that they need awareness, but seriously couldn't a short email saying X is going to happen at time Y suffice?

Im tempted to embed a Python/Ruby interpreter into my next project with a web interface to modify the code. Then I can do these minor changes without going through the 7 day process.

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

#52

Post by badclient »

This shit happens at my job and leaves me feeling depressed and at times questioning my own skills because I know and my bosses know that on my part, I just had to make a tiny, tiny change. But when you have a dozen such experiences, I feel like something is wrong with me because when the dust settles, this was a one line code change that took me a week to push to production. It also makes my bosses question my estimates. Of course, when I goto the other extreme and give a ridiculous estimate, that also pisses them off and makes them feel like I don't really know what I am talking about. Saying "I cannot provide an estimate" also does not cut it for the boss.

In the longterm, I can feel this killing a part of me. I have always been a start-up guy working for myself. Since getting my first full-time job, stuff that I would expect the start-up me to take an hour to do ends up taking days and weeks, even. I am aware of the (mostly legitimate) excuses to not take too much self-blame but at the end, it still feels shitty because I know, the start-up me knows, this should not have been a one week project.

Ah the perils of having a non-tech boss and coworkers and being the only tech guy. Reading stories like I experience at work is comforting in an odd way.

Here's how my typical story goes...

Boss: So can we make this little analytics thing your #1 priority for tomorrow?

Me: Yeah, as long as we don't have anything else for projectX(my #1 priority)

Boss: Well, do you?

Me: Not right now. But it can pop up any minute Jenny decides she needs something done.

--NEXT DAY--

Jenny: Hey this isn't working in ProjectX. Could you look into it?

Me: Sure. there goes an hour

Boss: I know you're busy but this is very urgent. Can we grab you for few mins for this meeting?

Me: Sure goes another 30 mins

...

Jenny: That thing you fixed. Can we undo it and push to production because I realized blabla?

Me: thinking wtf? Ok sure.

...

Amanda: Hey can you check if these 2 users signed up from same IP?

Me: You can check that in admin

Amanda: Where?

Me: The admin panel you emailed me info to when I joined the company..

Amanda: Oh right. Can you fwd me the email I sent, I can't find it. My gmail's not working right.

Me: Ok.

...

Before I know it, I have spent every day of my job troubleshooting shit to never really get in the flow of doing my own project assigned by my boss.

Boss(after a month): How's that project coming? I know you said it's a one day thing.

Me: Yeah but the next day we changed the specs in the meeting. Also, projectX is getting a huge rehaul.

Boss: But still...you said it's a week after that

Me: Yeah assuming I didn't have work for projectX

Boss: But you'll always have work for projectX

Me: Yeah that's exactly what I told you too

Boss: So where does this leave us? Can you finish it in next week? I don't think there is much work for projectX

Me: But...

Boss: You're the startup guy. We want you to push us to release stuff quick. When you give us deadlines and are so off, it makes us lose faith.

Leave work annoyed, put in a quiet weekend with no coworkers around and wrap up said project

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

#53

Post by crazygringo »

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…

> Or you could just hire responsible people and ask them to use their judgement

If you know a fail-safe way of only hiring responsible people who always have good judgment... then I hope you're being paid millions of dollars in consulting fees, because nobody has really figured that one out in a general way yet!! :)

Also, those people tend to be expensive... sometimes it's far more cost-efficient to hire less-perfect people, but put rules in place to minimize any catastrophic damage they can create, at the expense of efficiency.

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

#54

Post by Dove »

If you want a change request processed quickly, you should get someone in upper management to help you herd it through the system. Literally, take your VIP with you, and walk up to the desk of each admin in turn. Say, "Don't wait for Tuesday's meeting--approve this right now." And then walk to the next admin and do it again. And then walk to the test guys and say, "Drop everything and test this now." And then gather up the six essential stakeholders for the CCB meeting and say, "Impromptu CCB meeting, right now in the hallway instead of next month. Approve this."

I've gotten software changes that usually take two months to trickle through the system through in a day. You have to spend all day doing it, though, and so does your VIP.

But if it's really that important . . .

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

#55

Post by crazygringo »

benjaminwootton wrote: post #42
HeyLaughingBoy wrote: post #38

Earlier quoted context omitted.

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

I dunno... the odd bug fix has the potential to really screw things up, when the person fixing it isn't the person who wrote it originally, or it's been months since then.

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

#56

Post by brazzy »

boyter wrote: post #51

I just went through the same thing. Except I was smart (or so I thought) and had what I needed changed in a config file. PHB decided that it still counted as a "code" change because someone needed to log onto the box and change the config. Literally it was removing 3 characters from it. The only reason I even had it in the config was to avoid it being a code change to begin with. I argued back that in the time I woul…

the difference between config and code is largely illusionary, so PHB is right: both can break things and need to be tested.

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

#57

Post by crazygringo »

Dove wrote: post #50

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…

I agree in theory, but it's a slippery slope...

If you make one exception, then a month later, you discover that nobody is ever bringing old code up-to-date ever.

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

#58

Post by elemeno »

tcskeptic wrote: post #18

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.

Moving parameters somewhere else doesn't change the problem at all, only moves it to a different file. Altering a parameter that effects a large chunk of the system still needs the exact same amount of testing to be done, all you save is a compile.

For what it's worth. I'd also say that anyone who thinks that hardcoded parameters are always bad, probably hasn't worked on anything large or complicated enough yet. There are plenty of cases where you've got parameters which could theoretically change, but the likelihood is small enough that it doesn't make much sense to move it out to somewhere else - not coincidently, these tend also to be parameters which effect large chunks of the system and should never be changed without a solid business reason and a full QA cycle.

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

#59

Post by fleitz »

crazygringo wrote: post #53
fleitz wrote: post #34

Earlier quoted context omitted.

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…

> Or you could just hire responsible people and ask them to use their judgement If you know a fail-safe way of only hiring responsible people who always have good judgment... then I hope you're being paid millions of dollars in consulting fees, because nobody has really figured that one out in a general way yet!! :) Also, those people tend to be expensive... sometimes it's far more cost-efficient to hire less-perfect…

Following the rules to the letter also produces bad outcomes.

The issue is not that using judgement is perfect it's that using judgement usually produces a better outcome than blindly following a rule.

Yes, rules should be put in place for the most extraordinary circumstances or places that good judgement is known to fail. The rule has to prevent the bad thing to be effective while also not creating something worse.

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

#60

Post by ajross »

HeyLaughingBoy wrote: post #39
ajross wrote: post #26

Earlier quoted context omitted.

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.

Sure. That's the point behind refactoring, it makes changes to existing code flow more smoothly. But the case here doesn't fit that at all: the change as described was a change in configuration (that just happened to be stored in a code variable), yet it was being reviewed as if it were a new feature being added through development. That's the "cargo cult" part -- refactoring in the course of development is good. Rules demanding refactoring are bad, because they hit false positives (in this case, a high priority configuration change).
Post reply on HN