Comment by hyperman1 | Hacker News Reader

Comment by hyperman1 | Hacker News Reader

I first read this problem:

  micro-management, red tape, overly bureaucratic processes, and a lack of developer autonomy

and then this:

  essentially have no process. Everything is ad hoc, nothing is written down, deployment is a manual process, and there are meetings and interruptions all the time

They weird thing about enterprise is: I see both happen at the same time.

We have an issue tracker, but its a bad product and the metrics are heavily politicized. So we track our issues in excel. No way to know on whose excel your name appears.

We have a document sharing platform, but the fine grained access control makes it impossible to let the relevant people read the document. So we mail different versions around and forget to update the central truth.

We have architecture documents, but they have nothing to do with what runs in reality. We can't document what runs in reality because it would conflict with the offical architecture documents.

We have a release process that takes a week or a month, and many paper is written about risk and impact, test plans, deployment plans, resource availability, etc... But the actual risks must stay unspoken lest the release is cancelled. Tests were done on an environment that is forbidden to resemble production. People ignore the deployment plan and do whatever they like, and thank god because the deployment plan is unusable. People are not available when things go wrong, because the deployment plan booked them for 2 days for doing 5 minutes of work and they decided their part was done.

The worst problem: Instituting any real process is impossible, because officially there already is one.

I worked in architect roles for a while; I tried to make the architecture documents and systems match, it was impossible: I could not update the architecture documents to match what was in real life systems because on the first internal audit my skin would be on a stick, I cannot make the systems respect the architectural decisions because management not only allows, but is actively pushing for cutting corners for many, may reasons and they over-rank me or simply build systems not approved in non-compliant ways. The architect is that person you ask for confirmation if you think they will agree and ignore the rest of the time.

In the end everyone pretends there is no problem, but everyone knows there is one, including the auditors that selectively raise a bunch of small issues just to cover themselves with "we told you there are issues", but nothing big enough to trigger any alarms.

Non-IT companies do compromise a lot in IT; they don't want to compete for talent (because they are "not core"), they don't invest the right amount in IT (because they "don't need") and at the end of the day they cannot live without IT, so they cut corners with top management blessing. If there would be a SOX-equivalent for IT systems, most CIO/CTO would go straight to jail, don't collect 200.

This reminds me of something one of my CS professors said about when he worked in industry. They had a joke:

"We may work slowly, but our products are bad."

Nobody laughed, so he added, "You don't think that's funny today, but in five years you'll think it's hilarious."

Can confirm, I think it's hilarious.

Ooof, yeah, this rings familiar.

Or similar things, where actual risks may be spoken, even to power, and power will even thank you for raising them, and then proceed to ignore them because they're unpleasant and hard to address.

The best places are the ones that know about the risk matrix, and will insist you estimate probability and severity and place your risk there; and the matrix is capped at the usual 3x3 grid, obviously with a red square at the low-probability, disastrous severity square; and there's a rule that any risk on a red square is unaceptable and must be managed until it isn't.

All very reasonable rules, with the composed effect that you can never point a risk that inherently takes your system down (e.g. all of our ISPs go down), however rare it is.

Oh, definitely. I personally like the fact that there isn't something stronger than "risk", like "ongoing problem". I.e., "We're building a mobile product and have zero mobile devs". We're stumbling along and figuring it out as we go, so does it jeopardize the project? Well, no. Does it jeopardize timelines, and a whole bunch of non-functional requirements such as stability and security? Very, very much. But I can't quantify those.

Or "velocity is X per sprint, and the deadline you've set is 3 sprints, and we have 6X worth of stories". That's not a risk, that's a promise we'll not deliver on time. But then upper management just sees that risk and either just says "well, we need to hit it", adn expect you to magic a solution, or tries to solve it in the only way upper management knows how, by trying to throw more people at it, despite the fact they've all presumably heard of the Mythical Man Month.

This may be the worst thing i read on HN ever.

In what way? Language? Content? World view?

The horror i felt imagining how the people who work in such an environment might feel, if they haven't checked out allready.

(Edit) So it isn't actually that dramatic.

Trying to get out of it at the moment, but it’s seemingly very difficult.

You want to, and you will. Keep at it.

Don't weep too much for our damned souls. It's actually not that bad as it sounds, if only because everyone knows the rules are insane. A lot of the time, some manager goes to the meetings or shuffles the papers for us. We do loose a lot of time and its sometimes tiring, but there is also, if you want, real and interesting work to do, with noticeable real world impact. It also allows me to mix work and children, which is sometimes hard in smaller orgs.

Glad to hear that, spending time with your kids is worth so much more IMO, the greatest joy i feel is when i make em laugh.

Most of us would consider that nightmare scenario to work in. The closer to startup life you are, the less that exists. Smaller organizations die if they have that kind of dysfunction.

When everything succeeds, there's no problem. When it fails but is salvageable, it's a giant fingerpointing exercise that makes solving the actual problems twice as long, but ultimately has no consequences for the processes or people.

When things truly fail, people are thrown under the bus because they "didn't follow process." Management is unscathed.

And each part of the process is logical as to how it was developed. Because once a system is large enough, it develops enough scars that say "we won't fail again in that way." - and all failures are because the process wasn't followed.

Then, IT is outsourced because it's too expensive. The outsourced system openly skirts much of the process, but can't get the information necessary to build the right product and is seen as a cost center. Eventually, with enough failures, the trust is degraded and the IT is brought back in house. The cycle repeats.

You wrote it very well.

And yet, it's way too common...

This is how most non-tech Fortune 1000 companies run.

Reply on news.ycombinator.com