Hacker News Reader

Comment by zwischenzug | 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?

View on HN

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)

Reply on news.ycombinator.com