Earlier quoted context omitted.
Here is where the outsourcing happening in this story comes back to bite, though. It's basically impossible to write a good contract for an Agile development process. (The only time I've seen it at all is in gov't work, where cost-plus is the default way to pay, and it doesn't often produce good software.) If I'm the customer, why would I accept anything less than X for the amount of money I'm paying, and if I'm the…
Contracts for non-Agile processes are pretty worthless too if the project happens like this. If I understand correctly, the client ended up swallowing the cost for being intentionally lied to. In an Agile process, the client would be much more closely involved with the development, attend sprint reviews, ask questions, and be available for questions about whether to drop features or extend the deadline. The client ca…
Story: “It would be career limiting..."
231–240 of 342 posts
Re: Story: “It would be career limiting..."
#232Earlier quoted context omitted.
And that's how the Challenger blew up. Sometimes one side is right, and the other side is wrong, and it doesn't matter if they didn't "communicate and strategize" or "read the room". Obviously this guy is probably writing about a Javascript photo-sharing app or something and it doesn't actually matter, but it's the same principle. The managers who went ahead here would have gone ahead with launching the shuttle for t…
I assume you're referring to Feynmann's remarks in the https://en.wikipedia.org/wiki/Rogers_Commission_Report . The issue there was that management advertised a safety factor of 1 in 10^5 failures while the engineers thought it was more like 10^2, so numbers were fudged across the board to look reasonable. It really was a communication issue in that there was not accurate information on the riskiest parts of the laun…
Re: Story: “It would be career limiting..."
#233Earlier quoted context omitted.
Suppose you were a junior engineer working with a senior engineer. They gave you a task, and you came to a similar conclusion: it was their job to do X, but they weren't doing it. Would you simply tell them they're not doing their job, or would you ask questions, talk in private, and try to dig in tactfully? When I was 22 or so, I did go around telling a certain senior engineer that they weren't doing their job. I st…
> The people around me were trying to hint that things aren't quite as clear cut as it seems, but it took a swift kick in my backside to reboot my worldview. Was your rebooted worldview that you had been factually incorrect (i.e. the senior dev actually did do his work) or was it that you were factually correct, but hierarchy and office culture demanded that everyone pretend you weren't?
What a novice usually does not realize is:
It is easy to be right. What is hard is being actually helpful, coming up with a viable solution (vs. an idea).
In the posted article there simply was no such solution. It was not viable. Unacceptable.
Yes, an outsider with fresh eyes might see things differently and without bias, but most certainly the experienced team knows damn right that you're right (to some degree), but also knows that it's just not that easy.
Throwing "We are doing this all wrong" around is often just short of saying: "I just came here and I immediately saw that you all are idiots, you should listen to me!".
I'm not saying that fresh input can't be helpful, outsiders might bring in new tricks and ways, but being humble is way more helpful than being loud.
Re: Story: “It would be career limiting..."
#234There's no way to do true R+D with product driven budgeting. Perhaps "big corporate" has their own R+D and forbids divisions from doing R+D. Its really none of OPs business.
The backlog is always two years because budgeting is done for two years and the goal posts will change continuously to keep the backlog long enough to keep the budget afloat.
The goal posts always move continuously because R+D advances. If they close out and release 1.0 then the team and project have to shut down and transfer to the maint group. If you just keep the project eternally open then you don't have to re-create and open for bids and start entirely over to being version 2.0, you can just massage the requirements into 2.0 and keep going.
The individual contributor layer might not be cutting edge R+D, OP probably wasn't using framework-of-the-month or language-of-the-month but at the business level it might have been interesting R+D, far away in logistics-land or something.
A product driven company can bury paying for R+D this way if no one points it out, but if someone makes a formal report calling it out, that's a career limiting move so lets not look too close.
The other thing I've seen blow up is the business changes faster than the coders can keep up. If you have small enough line of business revenues you can over invest into automation; to put it in terms HN can understand if you engineer a hyper-scalable startup and only ten customers show up, that's a lot of money down the drain. Even worse if they're ten HUGE enormous customers you can stay in business a long time even if the automation would never, ever pay off with only ten customers. Or logistics invented a strategy that is obsolete before the coders can code it.
Some companies are really good at processing "build a bridge" Like a physical bridge cars drive over. Their internal systems will melt down conceptually at the idea of having a R+D dept with a permanent budget, even if it works and even if R+D makes a net profit. I had dealings with a place that, at a high level, made cranes, like industrial lifting cranes. They needed a R+D budget for R+D things but they only spoke business like a housing developer, you sign the contract, build the crane, find another contract. Smart companies that need to do R+D will find a way to do R+D even if they use really weird terminology to manage it.
The way companies like this move from one R+D project to another is "whoopsie the eternal product development is over budget scrap and do something else". Now they're probably got an eternal "fake product" around actually doing R+D using AI algos in the cloud or something. Or they're doing bland IT support, just endless Python CRUD for an R+D experiment in doing JIT logistics in a post-covid chip shortage world where the R+D is not in IT but the R+D is outside IT in logistics or accounting or marketing or something.
I can't guarantee this happened to OP but I've worked at places like that.
Re: Story: “It would be career limiting..."
#235If the client, which isn't it of the ordinary, then it shows exactly why it is career limiting to tell such truths to customers: company got paid regardless of project success.
Actual short term success for a services company is not defined in terms of the achievement of any particular outcome for the customer, but in terms of amounts billed and paid. As a result, it is a career boosting strategy for managers in short-term minded organizations to underestimate work scope so that a bid can be made for less money / less time than competition. Then, once the contract is signed and work has begun, "realize" that it's going to take longer and ask the customer for more time/more money. The customer may not have a great choice at that point, given they're already halfway down some path, and especially if their requirements were vague enough going in that this can all be characterized as new scope.
This dynamic isn't necessarily explicit or malicious. If people get promoted on the basis of contract wins (as opposed to on time, on budget delivery), for example, the incentives naturally reward overoptimistic managers.
I don't have a ton of experience here but whatever experience I do have tells me this is widespread in the computer services industry, as it is notoriously widespread in construction. The parallels with construction indicate this may be a structural feature of markets with information asymmetry...
Re: Story: “It would be career limiting..."
#236Earlier quoted context omitted.
Your take is exactly what is wrong with the culture. An existential problem is not a problem because you didn't sell it correctly. You first need to "massage" the individuals to create some kind of coalition. A coalition willing to accept basic facts or responsibility. If a CEO were to be a fly on the wall in this room and overhear it all, they ought to fire every single manager in the room. Quite obviously they are…
Any anecdotes of a company that was successfully split up as you suggest?
Re: Story: “It would be career limiting..."
#237Earlier quoted context omitted.
Everyone should rise to the political occasion. Why is that the engineers should not rise? Politics is how we solve problems without resorting to fists.
Engineering is the engineers domain. If engineers are expected to puppet master the managers then what is the point of the manager?
Re: Story: “It would be career limiting..."
#238Earlier quoted context omitted.
> Would you simply tell them they're not doing their job, or would you ask questions, talk in private, and try to dig in tactfully? Telling a manager "we uncovered work that wasn't in the original spec" isn't literally the same thing as telling them they aren't doing their job.
I think the confusion is, if their job is to execute a $60M contract successfully, and you tell them that it’s going to require an extra 12 months, you’re almost literally telling them they aren’t doing their job. Because arguably they weren’t. Their job was to guide the project successfully, which they didn’t do. In a situation like that, you can recover, but it requires tact. The end of this story was that they lef…
Pointing out that you've underestimated by X is pointing out something everyone already knows. And advocating to blow up the estimate by X so early in the project is arguing to piss the customer off and possibly walk away from $60 million. That's why everyone patted them on the head and blew them off. Everyone else understood the game but it's a bit gauche for them to explicitly explain what's going on.
Re: Story: “It would be career limiting..."
#239Earlier quoted context omitted.
Some of what you said is true, but your analog is a little off. It wasn’t a junior and a senior in the same role, it was a technical team deputized to do what they did, and a management group that apparently thought the deputies would fail, or convinced themselves their conclusions were wrong. The failure here is not one of lack of politics or communication on the part of the author or their team, but on the culture…
For what it’s worth, I don’t think they could have done more. But the conclusion of the story is to heroically drive off a cliff, and say “it’s all I could do.” That’s where I disagree. If it were me, I would have privately (emphasis on private) worked my way up the chain of command, trying to alert more and more people that there was a serious problem brewing. The meeting in the story was obviously going to be a fai…
And yes, I mournfully agree that this is the state of many organizations and management teams. But life is too short for me to put up with their bullshit.
Re: Story: “It would be career limiting..."
#240Earlier quoted context omitted.
The only people worse at knowing what the customer wants than management/sales is the customers themselves. It's really strange the first time you experience it.
Agree, never ask a user what they want But you can't go wrong with talking to users to understand the problems they are dealing with
https://www.amazon.com/Mom-Test-customers-business-everyone/...