Hacker News Reader

Comment by humanrebar | Hacker News Reader

> ...I notice more and more graveyards of abandoned projects and services running without anybody present who was involved in building or setting up.

I've seen this happen a lot in full-time-only shops. It's possible it happens more often in shops that lean heavily on contract work, but it happens everywhere.

It takes strong technical leadership to keep that sort of technical debt quantified and prioritized without killing productivity. Especially since it's generally a huge strategic issue, but not something that generally sinks a project, department, or company overnight. So ignorant or unscrupulous leadership can run the show for extended periods of time, get promoted, and not be held accountable for making a problem worse by ignoring it.

View on HN

The IT department in my company is an example of the result of a totally outsourced organization. At the top you have a huge layer of well spoken, very personable people who "facilitate", "align" and call meetings. They have no technical knowledge. Then there are a few "architects" who sit in these meetings. The architects come up with a solution and then send the work to India. At the place the work is actually done the people have no idea why things are the way they are and they often do nonsensical stuff. The organization never learns anything because next time around it will be a different set of people working on the system. It's really bad. The overhead is enormous and even the simplest project need weeks of meetings, planning and budgeting.

But to the CEO it looks like a lean organization because the permanent headcount is so low. I bet they would be better off if they had a fixed staff of experienced people who actually know the systems they are working with.

I see this type of organization often. I wonder if there needs to be a deeper evaluation of the costs of delegation. Institutional knowledge becomes even more abstract when trained algorithms and their developers are in the mix.

I was sitting in yet another meeting the other day and started thinking...

We have two of our managers on this call, one of their managers, three of their engineers, and me. But I'm only there for some vague technical guidance. I don't even know the system/language they're working in.

That's 3 managers for 4 technical people, 1 of which is simply babysitting. So really that's 4 people making sure 3 people do the work right.

Everything takes months.

That's actually a quite good ratio:). When I deal with our IT, it's usually 1 or 2 line managers, 1 business analyst, 1 or 2 project managers and 2 architects. Double this up if two groups are involved. None of them is involved in doing the work. The work goes to India and then if you want to get the work done right you try to schedule night late meetings with the one or two people there and explain everything from scratch.

From the outside it looks like they have a rigorous process of estimating, evaluating, writing requirements and stuff but it's almost pure overhead.

Ugh, pure overhead, exactly... Apparently someone produces some technical looking but actually vague document every week as a result of these meetings. Some date is thrown out, and _something_ is always deployed by that date, albiet buggy and destined to get rolled back. Eventually, someone figures out that the implementation doesn't actually work at all, and we go back to the weekly meeting with the "new requirements", and repeat until the thing actually works in some semblance of the manner that we need -- or run out of time, scrap it, and move on to more pressing things.

Maybe I should try scheduling some late-night meetings with the senior guy... He's sharp as hell, but we never get too technical during the meetings because that would just confuse people.

Yup, at one place I worked, I got the epiphany that everything was going straight to hell when I realized during the hazy stupor of an interminable conference call that I was the only non-PM. There were 6 people on the call. I got out of there shortly thereafter.

I've been on projects where between the project managers, technical managers, and other managers... there are 9 people in the room...and I'm the only technical resource -- on the project.

Fortunately for me, those projects are few and far between these days, but, earlier on in my career, they were common and frequent.

It depends. If you can’t manage contracts well, you can’t run IT either.

This is why SaaS and other productized services are so valuable. Buying O365 or Salesforce by the drink is dramatically more efficient due to the fixed deliverable and scale.

One of my favorite quotes:

"As an evolving program is continually changed, its complexity, reflecting deteriorating structure, increases unless work is done to maintain or reduce it." - Lehman.

The same is true with those old applications and services. They may have been running fine for years, but they are eventually going to have to be worked on.

The longer they wait, even though they are currently static, the more problematic they are going to be. They are going to break when something underneath them changes - and change is pretty inevitable. It's not just that they are going to break, the undocumented things built atop them are going to break.

I suspect I'm preaching to the choir, however.

Reply on news.ycombinator.com