Comment by austenallred | Hacker News Reader

Comment by austenallred | Hacker News Reader

> A single clueless person in a position of trust with non technical management and a huge budget

This is terrifying to me, especially as the CEO (I use the term because it's technically accurate in this case, not to be a douchebag) of a well-funded startup who is semi-technical. I can build basic apps and scripts and started out building things for the company, but now that we have real talent I would slow things down if I were in the code every day.

As such, I end up in a semi-product manager role, and consider myself responsible to make sure we're quickly shipping product in line with our goals, but at the end of the day I have to trust the people I work with, all of whom are experts in their respective areas. Luckily I can.

I have no idea how a non-technical product manager who has hired a contractor from an Eastern Bloc country would know when they're being reasonable and when they're just trying to screw him. That's just a recipe for disaster. It's a blind man in a new city taking an unofficial taxi cab. Makes me cringe.

I think that the Eastern Bloc is largely irrelevant. The programmers here are from top notch to complete morons. From anecdotal evidence - this is the same everywhere in the world.

I know of similar projects where the contractors who fucked up where from all around the world.

Incompetence knows no national borders.

In case that wasn't clear from the article, the project manager was a local. I'll update to make this clearer.

I lived in eastern Ukraine for a couple years, and some of the people there were the best engineers/hackers I've ever met; I wouldn't dispute that there are shops just as competent if not more so in the Eastern Bloc.

But it is relevant because there is no real legal recourse, so you're pretty much crossing your fingers and hoping that they won't screw you.

I would spend a proportionate amount of time looking into the firm and talk to past customers (where possible) before putting money anywhere, regardless of where they are located. Plenty of legal loopholes for domestic firms to deliver a less than desirable product and run away with the fees.

I too will say that all of the Eastern Block developers I have worked with, both on site and remotely have been excellent.

Not limited to software even. Whether it is a building contractor, an employee/r, the government, etc, if you do not have accountability in the system people will simply exploit it.

It is a truth of human nature, we are min-maxers to the core.

Perhaps he was mentioning that not to disparage them, but to explain why trying to communicate with them would be somewhat more difficult than a shop located in the same time zone?

Certainly, many EB programmers are very highly-skilled.

Definitely not to disparage them.

I didn't took it that way. It is just systematic risk of outsourcing. If a person is not in the same building with you, you are making a leap of faith (or sometimes even for a team in the same building).

I am sure that if we make an "Poll HN: At what distance away from you was the team/person that turned your project into nightmare?" we will find pretty even distribution in the brackets.

There are great coders and bad coders everywhere, but the more distant the team is (geographically and culturally) the more difficult it gets to evaluate them: It's more difficult to do interviews, it's more difficult to get background information and friends-of-friends recommendations etc.

Probably be better put as "contractors from a different country, speaking a different language, and with a different legal system." The specific country doesn't matter, what does in that you have no idea what they're doing and they have no idea what you want.

The original comment seems to have misquoted this part:

"I don’t blame them for this, they were placed in a nearly impossible situation by their customer, the (dutch, not associated with the company that built the whole thing) project manager was dictating what hardware they were going to have to run their project on (I have a suspicion why but that’s another story)"

Sounds like the project manager was also outsourced to a 3rd entity and may have had some vested interest in the hardware part of the project. This just goes to show that the financial interests of those steering the "ship" better be aligned with those of the "ship" itself, or hilarity/misery ensues.

This is all I see in IT over the last 20+ years. People that are IT directors (CIO, VP of "Engineering", etc.) that really have no idea what they're doing either on the financial side (budgeting, accounting, etc.) or the IT side.

It's how you end up with a guy from marketing as the CTO of the Sony branch that got hacked. This is every single company I've been in that's not a software provider. The thing is, they are ALL software providers now, they just don't know it yet.

to be fair it's incredibly difficult to find people that are both technically and financially competent.

Yep, that is usually why they get paid the big bucks, for their competency.

To my mind, this is a sign we're organizing things poorly.

If we design our organizations such that one person can make or break each project and we know there are way too few people to fill those roles, then frequent failures like this are the expected outcome.

In particular, I think the role of "project manager" is mostly wrongheaded. The theory is that you can take a person who knows nothing about the details, give them total power and perverse incentives, and then expect things to turn out well. I think it's only popular because it's an artifact of our current managerialist business culture.

I much prefer cross-functional teams where the team as a whole is accountable for results. I also think we technical people need to stop thinking of ourselves as minions and instead act as professionals. If a "project manager" told a professional (like a doctor or a structural engineer) to do something unsafe or wrongheaded, they'd say no. But software developers routinely go on building something terrible after token protest. I'd love to see that change.

Then don't rely on a single person to be both. Don't give full control without oversight to a single person for such an important project.

Oh god, that's me! I was offered a position as CTO two years ago, couldn't turn it down. Coming from a very strong technical background, the financial side of things has been challenging. I have never had to plan budgets before. I'm learning. CFO has been hands-on with me, helping as much as he can. First year I overestimated by 10%, second year by 20%. We are doing well, so that was a non-issue and my overshooting went into bonuses + new software licenses for the devs.

How in the world do you get more financial experience, short of bashing your head against it like I'm doing? Are there books you can buy that don't suck? We're going to double our development staff in Q1 (10->20) which is sort of terrifying....wish I had more knowledge!

The key challenge is that if you're very good at technology and finance, you probably aren't in an internal IT job. You're much more likely to be in financial services or a technology company. This is why so many internal projects become a mess.

May I suggest the book "Waltzing with Bears" by Tom DeMarco and Lister. It's simple tag line is "risk management is project management for grown ups"

As CEO your job (IMHO!) is not to "manage" the tasks so the project hits it's deadlines. It's to ensure that the risks in the project are recognised, seen as likely to actually occur and some action is taken Beyond crossing our fingers, to ensure that the project survives the risk becoming reality.

That might mean tests, or in house developers, or encouraging people to give bad news, it might mean hiring jacques before launch, it might mean building two teams to compete for launch whatever.

Just focus on the risks. Not the nice optimum path of perfectly executed tasks.

Antifragile by Nassim Taleb is also on the same theme. He argues that human, and life in general is (or should be) designed for robustness, not for optimal. Note that is not arguing against taking risk, but for better preparation for risks (both known and unknown).

Read the article again: it appears that the contractors said over and over "Hey, this software isn't ready yet, please please please let us fix this", and the PM said, "lol no fuckit shipit".

Ok, what does it takes to enable op code cache? It is not only about software, it is about many no brainers.

> Ok, what does it takes to enable op code cache? It is not only about software, it is about many no brainers.

From having worked on timelines like this, it was probably less about the time to enable it vs. "If we turn on op code cache and that breaks part of our code, we don't have time to fix it."

Solution w/ nebulous oversight and looming deadlines? Punt it to the ops team.

Agree, there might not be ops team as well, it is dev ops culture. No one in team was brave enough to take the risk. I am sure there are no units test as well to ensure nothing breaks.

I would venture to guess the pressure to release an immature product is not dictated by the PM but from the highest level of management. The PM was just a conduit of pressure from the business side. A good PM would have the backbone to say no and shield the development teams from the release pressure. The technically clueless is not a single person but the whole group.

Except that in this case that wasn't true. But that's usually how it would go, you're right about that.

Reply on news.ycombinator.com