It Takes 6 Days to Change 1 Line of Code

http://edweissman.com/it-takes-6-days-to-change-1-line-of-code

by jacobr • 14 years ago

457 231 14 years ago

edweissman.com

serverascode• 14 years ago

This happens waaaaaaay more than anyone will admit.

epochwolf• 14 years ago

Is it sad that I think 6 days is pretty fast?

protomyth3• 14 years ago

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.

MartinCron2• 14 years ago

Yes, it's very sad. I get kind of twitchy and nervous if code that I have written doesn't get tested and into production same-day or next day.

ctdonath• 14 years ago

So do the reasons why such infuriating processes are enacted.

zackzackzack2• 14 years ago

Why is the author still working there?

bengl3rt• 14 years ago

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 lines at a time.

Also, I can do a lot of damage in one line.

aslakhellesoy2• 14 years ago

> Also, I can do a lot of damage in one line.

Especially if it takes a week to revert it. You reap what you sow.

benjaminwootton5• 14 years ago

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.

aslakhellesoy2• 14 years ago

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

ajross3• 14 years ago

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 code. You never want to demand refactoring of existing code in order to patch features, that hurts, it doesn't help.

bobbles• 14 years ago

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 most seasoned programming in the company making a change.

5) They security processes might seem excessive but once again are probably in place due to issues in the past that have required the review/signoff be there to stop major disruptions getting through.

6) As someone who worked in QA for a while, there is no way in a hell someone can say "push this change through" without a strong questioning of why. QA is there (in most cases) to be that last line of defence. Often letting people know just how many people are really going to be affected by this change.

Being on a testing team often gives you a broader oversight of how all of the components of the code work together, while people working on one project can sometimes get tunnel vision on getting their thing out the door.

Edit: Just like to point out, I'm agreeing with you

HeyLaughingBoy2• 14 years ago

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

webcowboy• 14 years ago

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.

archangel_one2• 14 years ago

I agree that it's worth being careful on mission-critical code, but this isn't being careful, it's just box-ticking. Ed said he'd tested the actual change, but most of the time is taken up by shifting it out to some parameters file, lengthening its name and waiting for permissions.

helmut_hed• 14 years ago

No one seems to have pointed this out yet, but the code that runs your manufacturing line is indeed "mission critical". Furthermore it's likely that your customers demand that you have strict processes in place for changes, and can actually audit you at their pleasure. So being so bureaucratic about it is not surprising.

The Web 2.0 world works very differently, of course.

lmkg• 14 years ago

"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 over the second.

The problem is that things that scale up don't always scale down. The processes implied aren't that bad, for handling large commits to a large process. They're obviously overkill for small changes. But just because the processes are a negative effect on this change in particular does not mean that the processes are a net negative overall. More flexible processes could also end up being more trouble than they're worth, due to allowing (encouraging) sloppy work.

fleitz2• 14 years ago

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

VikingCoder4• 14 years ago

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

It is unacceptable to have a one-size-fits-all process, no matter what your business is.

eridius• 14 years ago

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

saraid216• 14 years ago

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

And as soon as you do, everyone thinks that their problem is a good candidate for the critical hot-fix path. At the very least, you now have to sink minutes per day into arguing them down from using it. Worth it? Possibly. But not always.

j_baker• 14 years ago

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.

akg• 14 years ago

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.

baha_man• 14 years ago

As mentioned above, Homer and Marge are servers rather than people.

tamersalama• 14 years ago

In many cases it's trivial to rollback. Why would you fight change if changing the change is as easy?

In this case process overrode rationale; and was cheered as a result on its own.

MartinCron2• 14 years ago

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 lines at a time

With proper test automation and continuous deployment, trickling new stuff in increments of four lines at a time is the right way to do it.

gacba• 14 years ago

And that is how creativity dies. Not all at once with a swift, decisive blow. More like the bites of 10,000 mosquitoes coming 1 at a time, about every 5 minutes so you don't notice that they've stolen a significant amount of your blood until it's too late.

brazzy2• 14 years ago

No, this is how creativity is shut out after one too many incidents where she wandered in, decided to be helpful and, due to imperfect understanding how things work, caused massive loss of productivity, money and reputations.

CamperBob22• 14 years ago

No, creativity is a process to be leveraged and managed like any other. This story is an account of life at a company where the process simply does not support the needs of the business. There are no excuses.

iirvine• 14 years ago

'Fuck that shit.'

maintenance programmer words to live by.

sp3324• 14 years ago

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

ojbyrne3• 14 years ago

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

jacobr• 14 years ago

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

Falling3• 14 years ago

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

gaius• 14 years ago

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

mangler• 14 years ago

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.

aninteger• 14 years ago

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.

zackzackzack2• 14 years ago

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

re_todd2• 14 years ago

Good point. When I'm stuck and management takes a couple days to get back to me and I have nothing to do, I take advantage of this time to learn new things. Maybe I'll read the man pages for "find" and discover a few new tricks. Or I'll read some tutorials on vim and learn some new things. I've learned a lot about MongoDB this year while waiting on roadblocks at work.

tcskeptic• 14 years ago

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.

elemeno• 14 years ago

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.

protomyth3• 14 years ago

I wonder if the place is covered by something like ISO 9000?

fierarul• 14 years ago

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.

rmc• 14 years ago

Time to change the character: 10 seconds

Time to find out what charater to change: 3 weeks

cpeterso2• 14 years ago

I've found that bugs that are very hard to debug often have the smallest fixes. Once you've discovered what tidbit of information you were missing, the fix is trivial. I guess this is a needle/haystack problem.

ww520• 14 years ago

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 are born. After couple years, things will get so stifled to the point of what OP was experiencing.

benjaminwootton5• 14 years ago

I liked this post on the topic - http://37signals.com/svn/archives2/dont_scar_on_the_first_cu...

vacri3• 14 years ago

"embed the learning in the organizational memory as a story instead of a policy"

That memory is hard to maintain with procedural changes in modern times, as employees move around quite frequently.

mjwalshe• 14 years ago

6 days you LUCKY LUCKY Bastard - i have user stories over 6 months old that haven't been actioned yet and had to wait 2 months to get a gwt verification file installed

cluda01• 14 years ago

What I identified with the most is the requirements creep that happens in QA/validation

twelvechairs• 14 years ago

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

munkydung• 14 years ago

What year did this occur? Do you get a lot of paper cuts from feeding the punch card reader?

Dove4• 14 years ago

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.

crazygringo3• 14 years ago

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.

protomyth3• 14 years ago

Yes, for an emergency change (change or there will be layoffs), this is a rather dangerous policy. The goal of any emergency fix should be "do as little as possible to solve problem".

I get the feeling that too many people in the chain did not treat this as an emergency. It seems very business as usual. When a company is talking layoffs, it is an emergency.

Dove4• 14 years ago

Yeah, I agree. The first time he told someone "Philip wants this done quickly" and they said, "Sorry, it's policy," the next move -- at least my next move -- would have been to walk to Philip's office and say, "Will you come tell this lady that this change is more important than that policy?"

I mean, they don't have a way to know it's really an emergency. Every engineer thinks everything's an emergency. There's nothing like the guy in charge standing there while they work to communicate THIS IS ACTUALLY AN EMERGENCY.

lotharbot2• 14 years ago

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 deciding against simple renovations (like adding a wheelchair ramp) because they didn't want to have to redo the entire building's wiring, widen every doorway, and put in an elevator.

If you require a massive overhaul to be tied to a minor fix, one likely outcome is that the minor fix simply doesn't get done.

cheatercheater2• 14 years ago

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.

boyter3• 14 years ago

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.

brazzy2• 14 years ago

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

boyter3• 14 years ago

I would argue that in this case where it was designed like that from the beginning IE detailed as how the system works then there should be no issues.

I did forget to mention it did go though a round of testing, which took less then 5 minutes to be verified as correct. It literally was 6 days of process wrapped around 10 minutes work.

gte910h• 14 years ago

Why stay?

boyter3• 14 years ago

Mostly due to certain parts of the job being very enjoyable and that this sort of thing isn't that big a bugbear for me to look... yet.

badclient11• 14 years ago

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

ajross3• 14 years ago

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 you. i.e. ask: "What things must I get done to make sure I'm successful long term?" (which is entirely different from "What is the highest priority thing I have been asked to do?") and make sure you prioritize your work to get those things done (which is an entirely different thing from "work on those things"). And if your workplace environment really doesn't permit that, move on.

badclient11• 14 years ago

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 really lasted more than ana few hours.

bceagle• 14 years ago

> Learn to prioritize for yourself instead of expecting your slag pile of a management structure to do it for you

What you are suggesting is easier said than done. I think that most good developers have the mentality you are describing...at first. When you work in an environment like this, however, you get worn down. You can only put up a fight for so long before you start getting all sorts of mixed up and you don't know what the f to do. If you took the best prioritizer in the world and put them in a corrosive environment like this one, the environment would eventually win out. I really feel for guys like the one that posted this original article and some of the subsequent commenters. I have been in that boat before and it is not fun.

rhizome• 14 years ago

Yak Shaving as an institutional affliction: http://projects.csail.mit.edu/gsb/old-archive/gsb-archive/gs...

metageek2• 14 years ago

Interesting; I've encountered "yak shaving" as meaning something slightly different: it's when your main task depends on a subordinate task which is long, difficult, and stupid--e.g., in programming, it's something which the tools should be doing for you. (Bonus points if you know that, on a different OS, or in a different language, the tools would be doing it for you.)

The original MIT meaning is closer to what I recently heard described as meta-yak-shaving, which is when, before you can start shaving the yak, you discover that each hair of the yak contains a subyak, and each subyak has to be shaved individually.

sax• 14 years ago

Just curious how many other folks see similar patterns of interruption? (i do)

rickmb2• 14 years ago

I see the familiar pattern of programmers not saying "no" and not explaining clearly what they need to work.

None of the other people here are being particularly unreasonable, they're just ignorant. And given that "how to work with programmers, writers and mathematicians" is not part of any educations, it's not really their fault.

pikewood2• 14 years ago

This will keep happening if you keep saying OK.

Try something like, "Can I get back to you in an hour? Boss wants me to finish this top priority item for him."

And if Boss asks you if you can finish it next week, say no. You're being asked to give an estimate, and it doesn't help to say "Yes, if [this thing doesn't happen which I know it will]". If they want you to be the startup guy, then act like you're the one in charge of your own schedule.

badclient11• 14 years ago

That works until they goto the boss and the boss comes to me...

"So I know your project is important but projectX is still our #1 priority so to the extent Jenny needs you please prioritize her work"

hkmurakami2• 14 years ago

Here's my suggestion: have your boss talk to Jenn and make her understand that you'll be spending the next day working on the boss' request. Any interruptions would have to go through the Boss, so that all parties are aligned.

This seems like a communication problem between the managers. (I can speak from experience, since I messed this up once when I reallocated our engineers' time without fully being on the same page as the engineering manager)

badclient11• 14 years ago

Ideally that should work but projectX is what the whole company is working on and key pieces of it are being tested throughout the day so it's impractical to have a cut off time.

badclient11• 14 years ago

ps: Now that I am leaving soon my boss is very interested for advice on how to attract tech talent. A part of me just wants to send him a link to this thread :)

I mainly stuck around because it was my first FT job and I'd promised myself I won't bail on it for one year no matter how bad. In past I've regretted quitting on projects too quickly...at least I won't have that regret here.

rapind• 14 years ago

For a job like that? Pay them. A lot (a good chunk of the company might suffice). Or suffer an extremely high turnover again and again and again.

sourishkrout• 14 years ago

1. Never tell anyone how long things take until you got a chance to sit down and make an estimate vs. guesstimate.

2. Never let anyone get you in the position to set priorities yourself (unless you're the boss). Refer them to your manager or whoever is highest in the chain of command and assigned you a task to make this decision.

This is really more a working culture problem. You'd think it's in the management's best interested to make sure nobody ever violates 1. + 2.

rorrr• 14 years ago

Solution: stop taking requests from people. Tell them to file tickets, and your boss will have to prioritize them.

dsrguru• 14 years ago

Just out of curiosity, and this is something I've been meaning to ask for a while, how does the whole startup only having one tech guy (who isn't a founder) work? I've seen this scenario referenced many times on HN and I'm still having trouble picturing what the incentives are to work for such a company (as opposed to being made a cofounder) when it sounds to me like you're doing at least as much work as they are. I would normally think the sum total of all development (I'm lumping things like specs, coding, documenting, and testing all together) to be at the very least close to 50% of a startup's value, so if there is only one developer, he or she would seem to be worth about half the company. Is this kind of startup less software oriented than the kind I'm describing?

undantag• 14 years ago

One backlog for new requirements, another backlog for incidents. Track your time working on the different backlogs (or even per-tasks) and pretty soon you will have some numbers to show the boss why new stuff isn't happening snap-snap.

darklajid• 14 years ago

Your problem is solved by a single word. Copy & paste the following : No. Alternative: No, sorry.

You don't look bad for declining requests. You will get your shit done. Just learn to say no. Really.

bbwharris• 14 years ago

As much as this sounds counterintuitive, say no, and stop being a team player.

Petty requests for emails that someone should have are their responsibility. If you think about it, why should your resourcefulness help them complete their job while it blocks your own progress?

Your boss is doling out reviews, he's #1 priority. Everyone else gets "no" and no access to your time without talking to him first.

"Being a team player" is a fluffy way of saying "do other peoples jobs for them". Sure, help people out and don't be a dick.

It does sound like a mess, but this type of mess exists everywhere. When you meld highly technical people with less technical people you will get these scenarios. Before you know it, you will be expected to replace the toner.

badclient11• 14 years ago

One of the main reasons I took a FT job was to become a better team player so in the long scheme of things, I always wanted to make this work out. Obviously it hasn't worked out too well but I think I have learned some critical lessons for my next gig!

grecy• 14 years ago

At my previous company we had the same problem, where people from all over the company would come up to us developers constantly asking us to do things which were great, but not really what we were supposed to be doing. Like you, we never got around to doing something that we said would only take a day.

One week we all decided to keep a notepad and paper next to our desks and keep a log of every time we were interrupted and asked to context switch and do something random. It was so bad, before the end of Monday our boss was so dumbfounded he completely re-jigged everything so it wouldn't happen like that again.

We ended up calling one developer pair the "consulting developers" each week, and only that pair could be interrupted. There was a huge sign above their desk advertising them for the week. We sacrificed one for the good of all, and it worked really, really well. AFAIK, they are still doing that.

badclient11• 14 years ago

This is great to hear. It is pretty much the problem/solution that I've diagnosed and stated in another post:

I think the root issue is they need a developer who just does tech support for the other 10 non tech people. And then a developer who can actually build shit quietly.

I will push this stance more aggressively having read your post.

underwater• 14 years ago

This is something the Scrum methodology is supposed to solve. It places the responsibility of prioritizing tasks at the hands of the stakeholders by making the tradeoffs between scheduled tasks and interruptions very explicit.

If you want something more light weight look into the Pomodoro technique. People can bring issues to you but only in breaks between blocks of uninterupted work.

If you go with either then you can explain away refusing to be distracted as merely following a proven methodology. This gives you an easy out as people will vent any frustration at it rather than you.

willpower101• 14 years ago

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

Dove4• 14 years ago

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

ojbyrne3• 14 years ago

That works once. Then the next time you go to each desk, the person there has already checked with their boss, and says "my boss says you need to go through the correct channels and if you don't like it, you need to talk to him."

Dove4• 14 years ago

That's why you have a VIP with you. If he's not her boss's boss, the whole thing is a lot less likely to work.

smackfu• 14 years ago

The tricky bit is that if there is a bug in the change, the VIP might suddenly be busy with other work.

And as you said, a smart VIP is there in the room, suggesting things get done. Explicitly not writing things down in emails.

cheatercheater2• 14 years ago

Wishful thinking. Each of those people has a thousand other things to do than to hold your hand all day long. Only works for things that are super-duper-important.

Additionally.. Going to "tell" on your buddies all the time and holding "the grownups" over them is terrible whinery. Everyone on the playground hates kids who do that.

CamperBob22• 14 years ago

Look on the bright side: if large companies weren't this screwed up, small businesses and startups wouldn't have a chance.

reinhardt• 14 years ago

Fuck. That. Shit. Seriously, I'm not exactly thrilled in my current startup role but stories like this give me a new appreciation for it.

rpikeca• 14 years ago

This is an unfortunate reality. People really do not care about all the work you have just the things they want done.

hcarvalhoalves• 14 years ago

The real WTF is that at the end, all it takes is the president giving a direct order to put the code in production immediately. That is, all the policies and processes just add noise to the interface between strategic decisions and operational tasks. That's how big companies fail.

avelis• 14 years ago

I find it troubling that they had to make a change at the point of layoffs to create a solution to prevent it. Couldn't they have discovered this trend before it got to that point?

faucet2• 14 years ago

is it only me or there is a (just one) line of code gone wrong on ed's comment handling server?

{"post_id":131434793,"html":"\u003Cdiv class='p_response_container' style='display:none;'\u003E\n\u003Cheader class='clearfix'\u003E\n\u003Ca href=\"http://edweissman.com/it-takes-6-days-to-change-1-line-of-co... class=\"p_view_all_link\"\u003EView All 16\u003C/a\u003E\n\u003Ch1\u003EMost Recent Responses\u003C/h1\u003E\n\u003C/header\u003E\n\u003Cdiv class='p_responses_list clearfix' data-posterous-responses-container\u003E\n\u003Carticle class='p_comment p_response' style='display:none;'\u003E\n\u003Cdiv class='p_info'\u003E\n\u003Cspan class='p_icon'\u003E\u003C/span\u003E\n\u003Ctime pubdate='1337295601'\u003E14 minutes ago\u003C/time\u003E\n\u003Ca href=\"http://tomakefast.com\\u003EPJ Brunet\u003C/a\u003E responded:\n\u003C/div\u003E\n\u003Cdiv class='p_comment_body'\u003E\n\u003Cdiv class='p_profile_photo'\u003E\n\u003Cimg alt=\"\" src=\"/images/profile/missing-user-35.png?1337287723\" /\u003E\n\u003C/div\u003E\n\u003Cdiv class='p_comment_text'\u003E\nHilarious, I love it.\n\u003C/div\u003E\n\u003C/div\u003E\n\u003Cul class='p_action_links'\u003E\n\u003C/ul\u003E\n\n\u003C/article\u003E\n\n\u003Carticle class='p_comment p_response' style='display:none;'\u003E\n\u003Cdiv class='p_info'\u003E\n\u003Cspan class='p_icon'\u003E\u003C/span\u003E\n\u003Ctime pubdate='1337296138'\u003E5 minutes ago\u003C/time\u003E\nkkudi responded:\n\u003C/div\u003E\n\u003Cdiv class='p_comment_body'\u003E\n\u003Cdiv class='p_profile_photo'\u003E\n\u003Cimg alt=\"\" src=\"/images/profile/missing-user-35.png?1337287723\" /\u003E\n\u003C/div\u003E\n\u003Cdiv class='p_comment_text'\u003E\nI agree and disagree at the same time. It does take a ridiculous amount of time to put something in production, unfortunately, but the scenario you described above is probably an exceptional case.\n\u003C/div\u003E\n\u003C/div\u003E\n\u003Cul class='p_action_links'\u003E\n\u003C/ul\u003E\n\n\u003C/article\u003E\n\n\u003Carticle class='p_comment p_response' style='display:none;'\u003E\n\u003Cdiv class='p_info'\u003E\n\u003Cspan class='p_icon'\u003E\u003C/span\u003E\n\u003Ctime pubdate='1337296154'\u003E5 minutes ago\u003C/time\u003E\nbob responded:\n\u003C/div\u003E\n\u003Cdiv class='p_comment_body'\u003E\n\u003Cdiv class='p_profile_photo'\u003E\n\u003Cimg alt=\"\" src=\"/images/profile/missing-user-35.png?1337287723\" /\u003E\n\u003C/div\u003E\n\u003Cdiv class='p_comment_text'\u003E\nDoesn't inventory cost $ and space? Maybe CFO should be involved too.\n\u003C/div\u003E\n\u003C/div\u003E\n\u003Cul class='p_action_links'\u003E\n\u003C/ul\u003E\n\n\u003C/article\u003E\n\n\u003C/div\u003E\n\u003Cdiv class='p_comment_form p_logged_in'\u003E\n\u003Ch1\u003ELeave a Comment\u003C/h1\u003E\n\u003Cform action=\"/responses/create\" class=\"new_comment clearfix\" id=\"new_comment\" method=\"post\"\u003E\u003Cdiv style=\"margin:0;padding:0;display:inline\"\u003E\u003Cinput name=\"authenticity_token\" type=\"hidden\" value=\"F6F7vP+9I0xtnokVneiKN6klXpPRM8ziSWl/D/arZxI=\" /\u003E\u003C/div\u003E\n\u003Cdiv class='p_not_authorized p_comment_section'\u003E\n\u003Cdiv class='p_additional_fields'\u003E\n\u003Clabel for=\"comment_name\"\u003EName:\u003C/label\u003E\n\u003Cinput id=\"comment_name\" maxlength=\"80\" name=\"comment[name]\" size=\"40\" type=\"text\" /\u003E\n\u003Clabel class=\"p_comment_email\" for=\"comment_comment_email\"\u003ELeave this field blank to comment.\u003C/label\u003E\n\u003Cinput class=\"p_comment_email\" id=\"comment_comment_email\" maxlength=\"80\" name=\"comment[comment_email]\" size=\"40\" type=\"text\" /\u003E\n\u003Clabel for=\"comment_toast\"\u003EEmail:\u003C/label\u003E\n\u003Cinput id=\"comment_toast\" maxlength=\"80\" name=\"comment[toast]\" size=\"40\" type=\"text\" /\u003E\n\u003Clabel for=\"comment_url\"\u003EHomepage:\u003C/label\u003E\n\u003Cinput id=\"comment_url\" maxlength=\"80\" name=\"comment[url]\" size=\"40\" type=\"text\" /\u003E\n\u003C/div\u003E\n\u003Caside class='p_login_options'\u003E\n\u003Cdiv class='p_asterisk'\u003E\u003C/div\u003E\n\u003Ch1\u003EWant to skip this stuff?\u003C/h1\u003E\n\u003Cp\u003ELogin with any of the following:\u003C/p\u003E\n\u003Cdiv class='p_login_buttons'\u003E\n\u003Ca href=\"http://posterous.com/login?flow=newcomment\u0026amp;jumpto=h... class=\"p_posterous_login\"\u003ERegister or login to Posterous\u003C/a\u003E\n\u003Ca href=\"#\" class=\"p_twitter_login\" data-posterous-jumpto-url=\"http://edweissman.com/it-takes-6-days-to-change-1-line-of-co... data-posterous-post-id=\"131434793\" data-posterous-redirect-url=\"http://posterous.com/oauth/init_oauth_and_redirect/?ssod=edw... data-posterous-twitter-login-button=\"true\"\u003E\u003Cimg alt=\"Sign in with Twitter\" src=\"/images/site/sign_in_with_twitter.png?1337287723\" /\u003E\u003C/a\u003E\n\u003C/div\u003E\n\n\u003C/aside\u003E\n\u003C/div\u003E\n\u003Cdiv class='p_comment_section'\u003E\n\u003Clabel for=\"comment_body\"\u003EComment:\u003C/label\u003E\n\u003Cdiv class='p_comment_area'\u003E\n\u003Ctextarea cols=\"40\" id=\"comment_body\" name=\"comment[body]\" onChange=\"if (this.scrollHeight \u0026gt; this.clientHeight \u0026amp;\u0026amp; !window.opera){this.rows += 1;}\" onKeyPress=\"if (this.scrollHeight \u0026gt; this.clientHeight \u0026amp;\u0026amp; !window.opera){this.rows += 1;}\" rows=\"5\"\u003E\u003C/textarea\u003E\n\u003C/div\u003E\n\u003C/div\u003E\n\u003Cdiv class='p_comment_section'\u003E\n\u003Cinput id=\"comment_post_id\" name=\"comment[post_id]\" type=\"hidden\" value=\"131434793\" /\u003E\n\u003Cdiv class='p_submit'\u003E\u003Cbutton button=\"true\" class=\" action_button\"\u003E\u003Cspan class=\"\"\u003EPost this Comment\u003C/span\u003E\u003C/button\u003E\u003C/div\u003E\n\u003C/div\u003E\n\u003C/form\u003E\n\u003C/div\u003E\n\n\u003C/div\u003E\n","responses":[{"name":"PJ Brunet","body_html":"Hilarious, I love it.","created_at":"2012/05/17 16:00:01 -0700","body":"Hilarious, I love it.","post_id":131434793,"id":11028186,"display_name":"PJ Brunet","comment_type":"comment","display_url":"http://tomakefast.com,allowed:true,display_photo:/images/pro...},{"name":"kkudi","body_html":"I agree and disagree at the same time. It does take a ridiculous amount of time to put something in production, unfortunately, but the scenario you described above is probably an exceptional case.","created_at":"2012/05/17 16:08:58 -0700","body":"I agree and disagree at the same time. It does take a ridiculous amount of time to put something in production, unfortunately, but the scenario you described above is probably an exceptional case.","post_id":131434793,"id":11028197,"display_name":"kkudi","comment_type":"comment","display_url":null,"allowed":true,"display_photo":"/images/profile/missing-user-35.png"},{"name":"bob","body_html":"Doesn't inventory cost $ and space? Maybe CFO should be involved too.","created_at":"2012/05/17 16:09:14 -0700","body":"Doesn't inventory cost $ and space? Maybe CFO should be involved too.","post_id":131434793,"id":11028199,"display_name":"bob","comment_type":"comment","display_url":null,"allowed":true,"display_photo":"/images/profile/missing-user-35.png"}]}

vgnet• 14 years ago

Hey, thanks for wrecking page display for me! :)

faucet2• 14 years ago

it was just one line! :-)

EternalFury• 14 years ago

I can relate to that. Maybe 70% of the defect corrections I make in our highly complex and optimized code base are less than 10 lines worth of code.

It can take between between 24 hours and a week to figure out what those few lines should be, though. And that is extremely frustrating.

dools• 14 years ago

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 trivial importance when compared with the health of the company as a whole.

It's all about risk right? Like if the company wants to spend $50,000 to change 1 line of code, and it's not going under, then that's obviously the right decision. It's just the same as spending millions of dollars per year on insurance and then complaining when the place doesn't burn to the ground.

The "move fast and break things" attitude of Facebook works for Facebook - it's a different company.

Small startups can break whatever the hell they want because they're not making any money yet.

An established company with a functional system that makes money has to take measures to protect it, because that functional system is where all the value is in the company.

aneth• 14 years ago

I generally agree that this process doesn't sound all that terrible for code that controls a large, live manufacturing line. Try changing the code that runs a pacemaker - you'll learn all sorts of things about process.

This line however is the road to hell:

"if the company wants to spend $50,000 to change 1 line of code, and it's not going under, then that's obviously the right decision"

Just because a company is successful does not mean it does everything right and does not contain the seed of its own destruction.

lukeschlather2• 14 years ago

Really, I think the problem with this scenario is not that the company wanted to "spend $50,000 to change 1 line of code." The problem is that management wanted to spend $500 to change one line of code, the dev team spun up to spend $50,000, ended up spending maybe $5,000 before management told them "no really, we don't care about what you think, give us the $500 fix."

joe_the_user• 14 years ago

Indeed,

Also, it sounds like it didn't take six days to change the lines. It sounds like it took maybe two hours spread over six days. Not being able to pivot immediately might be a problem but it sound like it would the president's problem, not Ed's problem. But it might be anyone's problem. It just takes a while to do stuff when you're multi-tasking.

Did you know the computer also wait many instructions before it performs the one you asked for, even in "c"?

rickmb2• 14 years ago

Besides that, most of the delay in this story was not caused by process but by human error and sloppy work by the OP.

There are some hints of organizational dysfunctions along the way, but those were not what caused the major delays.

Without those screw ups, it would have been 2 to 3 days from decision to production. That's pretty decent for any company larger than a 10 people start up.

zwischenzug• 14 years ago

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 someone that's obviously guilty?

IgorPartola2• 14 years ago

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 security people stepped in and basically said "well, this might be delayed because it doesn't follow our standards and we don't have all the sign-offs. This might mean layoffs, lost profits and so on, but damn it we have to follow our policies!"

Sounds like the IT dept. is not enabling the business. They are, instead, hijacking it, substituting their own priorities for those of the whole enterprise.

GFischer• 14 years ago

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

chrismealy• 14 years ago

Is this a story or a real thing that happened?

peacemaker• 14 years ago

It's exactly this situation that made me leave a large company after only 5 weeks. I'd come from a smaller, more agile environment and having to go through multiple layers of process and bullshit just to get the simplest thing done was just too much for me. I know 100% that if I'd have stayed there I would have ended up hating my job and affecting my passion for writing code.

The main situation I remember is a code review of a few lines I'd written kept on being rejected by some of the more process-indoctrinated programmers purely because I didn't use the correct type of verb in the first sentence describing my change! I mean, when that is the shit that matters and not solutions to problems, I'm out.

marbletiles• 14 years ago

"It Takes 6 Days to Change A Fundamental Business Practice" sounds a lot more reasonable.

Should you be able to extend the backlog of a factory by an entire month just by changing a variable, pushing a build and going for lunch? No.

mkopinsky• 14 years ago

The problem, imo, is not that it took 6 days of reviews to change a major variable. The problem is that the reviews were entirely immaterial to the actual change taking place. Whether variables are hardcoded, have an audit trail, and use proper naming conventions will have no impact on ACTUALLY mitigating the business risk of making a giant change.

chris_wot• 14 years ago

Better that than they push the line of code and everything stops working for a fortnight!

parasubvert• 14 years ago

(rewriting this a bit to make it clearer).

It's clear that a mission critical change needs oversight and risk mitigation. But think of the waste of this process from the Lean perspective: Waiting, Handoffs, Checking, Inspecting, Obtaining approvals, Reviewing, Filing, and Rework.

IT groups need shepherds to be able to guide these things through the system of checks and balances. If you look at this scenario, Ed, the programmer, was the orchestrator. The end-to-end process was ad hoc, and not designed purposely. There were actually several processes at play, designed by different departments (IT demand, support, delivery, QA, etc.), with different value systems, and the interaction between them isn't well defined towards the end value of "shipping software changes that work". The division of labour across review, testing, etc., without incentivizing end customer results, and minimizing waste, has devolved into a bunch of school marms that redline all documents or code given to them without actually working to help with the end goal.

The "this test plan isn't good enough" for example is a near and dear to me. Why can't QA dedicate a resource for a brief period to help make it better? Or at the very least, give guidance on the what they want to see for approval? Usually this (and ornery change management boards) wind up being the primary source of senior management overrides - the QA group doesn't improve quality, it just slows down change thus maintaining the current (functional) mediocrity.

IF the process was shepherded by a manager to actively involve QA, Code Review, Change Management, etc. earlier, Ed might be less frustrated, and it would have been done in 3 days. ;)

Karunamon2• 14 years ago

This reads eerily like my job, just s/code change/system change request

Love the my job, hate the bureaucracy.

chaostheory• 14 years ago

> Pissed off hours spent on Hacker News: 14.

Seriously I've already mentioned this for your last post, but imo it's really time to leave your job for something else Ed. Unnecessary stress lessens the quality of your life, as well as lowering its total lifespan.

hedgie• 14 years ago

I'm very lucky to work in a place where they understand the limitations of this policy.

Most of the product we work on (not a CRUD app) is finished or at least at a fairly mature state. But the area I work on is not. For a while they harped on us about following the process. But due to their lack of interest on what we were doing and some managers protecting us, we ended up able to make rapid changes in response to test failures, often several times a day.

It was incredible. They would seek investigations through change requests on bugs found in testing. Immediately after they were entered - before the change request even went to the overseeing group of project engineers and subject matter experts - we would tell them what caused the problem and write that we had committed a fix to the mainline. This circumvented days of waiting for a response that would have blown our schedule apart.

It paid off big. Today for the first time our tests all started passing. They've been failures for years and no one expected anything close.

There's a time for process. When a lot can break or you have a finished/safety-critical product you want to lock it down. But in initial development of new features, you have to throw it out and do what's right.

For a while they were demanding change control with CRs over software that had never been written or run successfully. Why even bother writing the CR if it never worked in the first place? That means the software wasn't done in the first place, not in a state requiring change control!

It was unusually rapid iteration between the test and development teams, who should sit next to each other and immerse themselves in making the software work. Only by rapidly uncovering and overturning problems like this can you ever get something close enough to stable to lock it down this way.

Development and test respected each other, understood what had to be done, and by working together discussing behavior and the test environment were able to determine what the software should do and how best to test this functionality.

There were times where waiting for the process would have taken us 5 days to get approval to fix a bug. By talking with our project engineer and going ahead with the testers - who realized it was not the time to stick to formal process - we were able to succeed.

I'm very lucky. The testers were cool and understood the state of the software and were willing to shout across the cube and explain what was failing. We worked together and managed to succeed by knowing when a process was important and when the managers would be happier to go around it.

The problems encountered here are mainly about people. We had testers and others who trusted and worked with us. When you don't have that - like the author of the article - it takes some social engineers and lawyer like knowledge and parsing of company policy to get around the problems.

ovechtrick• 14 years ago

THANK YOU.

This couldn't have come at a better time. Describes my current situation perfectly.

I changed 1 line of code today. It's going to require me to call into 2 review meetings to have it approved. These meetings happen once a week. 2 weeks to get this code to production. UNBELIEVABLE.

I think it's time for a new job.

Sukotto• 14 years ago

I thought the last line would read "Weeks of notice given: 2"

Why are you putting up with that crap Ed?

nnethercote• 14 years ago

"you are responsible for fixing preexisting errors that violate new company policy"

That's insane.

zszugyi• 14 years ago

Seems like the "boy scout rule" got out of control.

brudgers• 14 years ago

This is a case where programmers are overhead not production and the "system" is sized to handle peak loads.

Another way of looking at it, "It Takes 6 Days to Prevent Layoffs."

That's pretty damn efficient from a business standpoint.

And pretty damn important from a human one.

yason• 14 years ago

Excess code review rules and company policies are, in effect, a defense against the stupid. They're in place to limit or slow down the damage potentially done by stupid employees.

However, they're also a defense against the smart.

If there's a barrier erected to weed out stupid changes the barrier works to weed out smart changes as well. The barrier can't distinguish smart changes from stupid changes, and the people operating the barrier can't easily do that either since their asses are on the line in case they miss a bad change. As you can see, even the word of a higher manager can't change that since the defenses are spread out so wide: there's always some additional policy that requires more and more authorization from more and more people.

Good systems always support skunkworks approaches where good programmers have an unofficial half-sanctioned way to subvert the policies when needed.

389401a• 14 years ago

This is how individuals working with open source software beat a large corporation where by all accounts they should not stand a chance. Bureaucracy is the Achilles Heel.

nerdfiles• 14 years ago

"Also, dude: learn to say no." This is horrifyingly bad advice, and in fact I doubt it even acknowledges the problem. It takes time to say "no". Are you telling us to learn "the path of least resistance" in saying "no"? Is this legitimate advice?

At a previous development gig, I would have to learn how to say "no" to at least 5 different types of people. And quite honestly, and candidly, I think this advice is absolute bullshit. I genuinely believe it wholesale ignores all the junk-news that's bubbled up around Zuckerberg's attire at meetings, the joke about Ohanian's suit on Bloomberg TV, etc., the culture of corporatism. If you say "no" enough, you end up like Zuckerberg: An Emperor with no Suit. (Or to put it less abstrusely: "This guy won't play ball.") And if you say it with the force and cavalier quality I think you're thinking: you get fired.

This advice prompts me as if a manager, if it's taken without the gusto of the frustration we're all feeling. And I don't want to be a manager.

Let me put it this way. Are you saying there's a verbal silverbullet that shoots down CEOs, Team Leads, Content Authors, Co-Developers, Designers, IAs, Managers, Testers, Team Members, etc.?

I suppose many others have already said this: _easier said than done_.

deepGem• 14 years ago

Ditto for most of the IT services companies in Bangalore. Oh just add "Project Manager X chasing the required parties" between every line in that article and perhaps add another 3-4 day delay as most of the teams don't work in the same time zone.

cnbeuiwx• 14 years ago

This happens at my job too and I want to kill myself when it does. I get so frustrated. All these work protocols and slow useless software that prevents me from being effective at work.

I usually find a way to make things work by going outside the protocols and just fixing the problems. Its not the problem that is hard, its the stupid damn protocols and official ways of doing things that makes it very hard to get something done.

Decisions being made by idiots who have no clue how to allow people to work in a efficient manner, or how much money they lose by people sitting around doing nothing, waiting for some useless step in a useless process.

Seriously, I can feel the rage coming just thinking about it while writing this! What the fuck happened to this industry...

drivebyacct2• 14 years ago

This thread reminds me of two lessons that I'm thankful I've learned young:

1. Processes exist for a reason. They're often annoying and sometimes overkill and unnecessary, but they're often there as a result of a past problem.

2. The whole top thread about communicating and literally ignoring people reminds me of my roommate who bragged that he was a good leader, meanwhile telling me that he would simply ignore his teammates because they annoy him. This is why "geeks" get the stereotype that they can't interact with people and it's why programmers with business and communication skills are so valuable and sought after.

geekus_maximus• 14 years ago

I smell opportunity. Companies that are as archaic and inflexible as this deserve to be outdone.

tluyben2• 14 years ago

This happens at both big and small companies; I worked with a company of 30 people who had this 'in place' already because the CTO was had 'experience in leading very large projects'. It was kind of annoying.

S_A_P• 14 years ago

While I can both relate and empathize with the story here- the initial "crisis" seems forced and arbitrary. Once a company becomes sufficiently large to mandate a promotion process like the one described in this story, the management would probably know that there is no "immediate" changes that can be made unless they want to bypass those processes. Further, if it took 6 days to change a line of code to meet everyone's standards and satisfy requirements, imagine how long it would take to push through a layoff. :)

rubynerd• 14 years ago

This is the model which my Computing coursework bases around, you get something like 6 marks for code and 8 marks total for a "test plan"

The best thing? I think I've lost the majority of marks for using RSpec instead of 100 screenshots

jiggy2011• 14 years ago

I have to opposite problem, almost no process at all.

I'm not sure which is worse, having to wait 6 days to do a change or having people request (often trivial) changes to be deployed the same day they specified them and having people going round editing .php files directly on the production server.

It Takes 6 Days to Change 1 Line of Code

Related Stories