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.

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.

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

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.

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.

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.

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.

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

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

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.

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.

'Fuck that shit.'

maintenance programmer words to live by.

Why is the author still working there?

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.

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

(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. ;)

This happens waaaaaaay more than anyone will admit.

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

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

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.

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

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.

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

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

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.

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

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.

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

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.

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.

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.

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

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.

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

Why are you putting up with that crap Ed?

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

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.

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.

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?

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.

Is this a story or a real thing that happened?

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

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

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

Love the my job, hate the bureaucracy.

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

That's insane.

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

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

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.

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

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"}]}

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

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.