Hacker News Reader

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?

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.

IME process doesn't spring fully-formed from the head of Zeus.

You get test plans when somebody goes cowboy on live code and breaks tangentially related processes. You get security reviews when somebody goes cowboy on live code, everything looks great, and then a month down the line you lose days of work when someone changes a password. You get mandates to create parameter files when someone gets burned having to run through this entire process over and over again when business rule changes back and forth.

The reality is that once this change is done the proper way and the business parameter is moved to a file, the company will never lose time over this issue again. It will be configurable just as fast and responsive as we all feel it should be, without any concerns about breaking things down the line.

Is it frustrating? Sure. But that doesn't mean it's wrong.

Going cowboy on live code, even for something as trivial as changing a 3 to a 4, can and has created large problems.

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

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

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

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

He may have changed only a single line, but making the queue 4 months instead of 3 could break other parts of the system. Perhaps the "save data" and "backup" functions assume 3 as well, so you'd lose data. Perhaps other assumptions are made in the code, so with a 4 you'll end up with buffer overflows. Those test and security people are in the process to catch these issues before there are problems. It may seem a trivial change, but people make assumptions all the time.

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

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

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.

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.

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