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

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

#231

Post by IgorPartola » Sat, May 19, 2012, 12:43 PM UTC

roc wrote: post #195

IgorPartola wrote: post #191

Earlier quoted context omitted.

The business wanted to s/3/4/ on a single line. The reality is that President, CEO, CIO, etc. don't really care about whether this parameter is configurable, if there are specific test plans, if the test team is happy with the variable name, etc. They don't want to do a layoff. So they asked the developer to perform the s/3/4/. The developer did so, reasonably. Then it sounds like the self-righteous testing and secur…

IME process doesn't spring fully-formed from the head of Zeus. You get test plans when somebody goes cowboy on live code and breaks tangentially related processes. You get security reviews when somebody goes cowboy on live code, everything looks great, and then a month down the line you lose days of work when someone changes a password. You get mandates to create parameter files when someone gets burned having to run…

Agreed. Process comes from a need. My point is that it sounded like the test and sec. people were not trying to speed it up. They seemed to offer little help or alternatives. Perhaps the communication process broke down. Did Ed know the importance of this change? Test and sec. certainly did not seem to.

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

#232

Post by crosvenir » Sat, May 19, 2012, 2:28 PM UTC

0x0 wrote: post #229

masklinn wrote: post #182

Earlier quoted context omitted.

> If people start with "Hi, I have a problem" and don't state what the problem is I just respond with "drop me the details and I'll have a quick think" and get back to my work. If people start with "Hi, I have a problem" and don't state what the problem is I close the chat window . My work IM's status clearly states "if you have a question, ask it, don't ask if you can ask", time wasters simply get ignored. > Some pr…

I'd answer that "I have a problem" with "I have a solution".

I do this all the time and add, "I like this game. Your turn." It normally gets a smile (at least in person), but doesn't really help with the flow problem.

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

#233

Post by lotharbot » Sun, May 20, 2012, 2:59 AM UTC

cheatercheater wrote: post #228

lotharbot wrote: post #149

Earlier quoted context omitted.

This is similar to laws that require buildings be brought entirely up to code any time any renovations are done. The intent is to keep buildings up to code, but one of the nasty side effects is that buildings which are already substandard continue to deteriorate because of the massive expense (in time and effort as well as money) that is required. I've seen half a dozen instances with churches and other nonprofits de…

If you require a massive overhaul to be tied to a minor fix, then you have let the thing rot for too long. In your example, those buildings that deteriorate will at some point stop being liveable, and lose in value, which will finally mean that the proprietor's failed business approach will become weeded out. I, personally, welcome this sort of development.

"Being out of code" isn't always a result of deterioration or neglect; sometimes it's just a matter of the code changing. Structures built in the 1950s may not have, for example, ADA-compliant accessible restrooms, though the restrooms may be perfectly usable. But putting in something as simple as a wheelchair ramp at the front door might require also remodeling every single restroom in the building to be ADA-compliant.

I've seen half a dozen small religious groups go through this sort of problem -- because they can't afford to make the church/synagogue/etc completely accessible, they aren't able to make incremental improvements. The buildings remain perfectly functional and well maintained and retain all of their value, except in the eyes of the one guy in a wheelchair who can't get a ramp put in because his church can't afford to drop 15 grand on all the other not-very-useful-but-required stuff.

Relating this back to code: if you have a policy that requires any old code must be brought up to new standards any time it's touched, then there are at least some occasions in which someone could have made a useful incremental improvement, but is stopped by a stupid policy decision that would saddle them with burdensome work. The net result is that small, high-value fixes get put off because of large, low-value busy work.

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

#234

Post by willpower101 » Sun, May 20, 2012, 8:02 AM UTC

badclient wrote: post #52

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

My gmail's not working right. -- Hahahaha. I hear this all the time.

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

#235

Post by roc » Sun, May 20, 2012, 2:55 PM UTC

IgorPartola wrote: post #231

roc wrote: post #195

Earlier quoted context omitted.

IME process doesn't spring fully-formed from the head of Zeus. You get test plans when somebody goes cowboy on live code and breaks tangentially related processes. You get security reviews when somebody goes cowboy on live code, everything looks great, and then a month down the line you lose days of work when someone changes a password. You get mandates to create parameter files when someone gets burned having to run…

Agreed. Process comes from a need. My point is that it sounded like the test and sec. people were not trying to speed it up. They seemed to offer little help or alternatives. Perhaps the communication process broke down. Did Ed know the importance of this change? Test and sec. certainly did not seem to.

In the enterprise, it's always an emergency. If it isn't, it gets ignored, because the pipeline for getting 'non emergencies' done is constantly pre-empted for emergencies.

That said, every good process has the ability to handle exceptions. If it was truly the emergency it sounds like, he should have been able to make the change to get it up and running ASAP and then made the change properly through the normal process.

But the question of whether an "emergency" truly is, is a complicated one.

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

#236

Post by scottbruin » Mon, May 21, 2012, 8:54 AM UTC

badclient wrote: post #82

ajross wrote: post #72

Earlier quoted context omitted.

This doesn't sound like a process problem at all, actually. Really it's the reverse: your work environment is a mess, no one has the ability to do their own job except to bug you to do things they need. And that's a disaster too, but it would be helped by adding process, not hurt. Also, dude: learn to say no. Learn to prioritize for yourself instead of expecting your slag pile of a management structure to do it for y…

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…

Sounds like you need a project/product manager type shielding you from BS. Get in touch if you're looking for new opportunities in Socal area.

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

#237

Post by GFischer » Tue, May 22, 2012, 8:32 PM UTC

zwischenzug wrote: post #165

dools wrote: post #93

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

I don't see the problem either. The article is extremely self-centred, and doesn't deconstruct why this is bad for their business. The programmer's job is to help the business achieve its ends. If she feels stymied by process she needs to discuss it with the business. If she's criticised for taking too long she needs to lay out where the time went. Imagine if lawyers wrote articles about how it took months to convict…

"Imagine if lawyers wrote articles about how it took months to convict someone that's obviously guilty?"

If they don't, they should :)

(and no, I'm not kidding. Justice would be better served by better judicial processes)