[jiggawatts]

The problem is that the "fast" part is in quotes because it's glacially slow as soon as you get past the initial MVP or demo.

I see this idiocy everywhere, to the point that many clouds are now advertising "Day 2 operations" like it's a new thing to be doing things for more than one day.

Everywhere you turn, it's: "Get started quick", "Quickstart", "Deploy to <cloud>!", etc...

What do you do after deployment is... crickets chirping, wolves howling, and a tumble weed rolling slowly past.

CORBA, Java Remoting, .NET WCF, WS-*, etc... are complex technologies that can't be trivially poked and prodded with curl or a repl. What they provide is tooling and long-term velocity and safety even with hundreds of developers on the team.

Heck, even as a solo developer I strongly favoured the "proper" RPC systems. I could define a class type once, and then Visual Studio or IDEA or whatever would spit out tens of thousands of lines of error-free boilerplate code that otherwise I would have to hand-roll.

You can't imagine how depressed it makes me when I see some Web API guide that starts off with a cheery "this is a simple..." and then there's five hundred pages of English text.

Look. Sure, if you're an Indian outsourcer developer, this is great. You can bang out monotonous repetitive code like a meat robot and collect a pay check your subsistence farmer parents could only dream of. You can do this for years, and never have to think, or be creative, or risk your job security.

But people that need to get things finished, past day two into day five hundred? We use the good stuff, with automation.

Half the world still builds roads with hand tools. Where I live, we build roads with heavy machinery.

That's the difference. Any idiot can pick up a hammer and say "road building is easy". They'll still be building that road with an army of workers a year later.

[lelanthran]

I upvoted your comment because it's largely accurate.

However, I would caution against blanket stereotypes like this:

> Look. Sure, if you're an Indian outsourcer developer, this is great. You can bang out monotonous repetitive code like a meat robot and collect a pay check your subsistence farmer parents could only dream of. You can do this for years, and never have to think, or be creative, or risk your job security.

A lot of the outsourced indian devs do indeed match that description, BUT the majority of them that I know of don't want to "bang out monotonous repetitive code like a meat robot and collect a pay check ".

They want to create novel and creative things like everyone else. That they're stuck in the modern equivalent of the assembly line is really not their fault, and most devs, outsourced or not, are in that space anyway.

[geodel]

> BUT the majority of them that I know of don't want to "bang out monotonous repetitive code like a meat robot and collect a pay check ".

Well, majority of you know are not majority of actual IT workforce in India. As some one who worked for a decade or so with Indian IT vendor and worked with outsourced developer till today. Most of them have no interest beyond meeting client requirement which is just code word for a massaged resume contain exact keywords that clients put in job requirement.

> They want to create novel and creative things like everyone else. That they're stuck in the modern equivalent of the assembly line is really not their fault, ..

Well they could've take low paying job that's creative. But IT jobs offer high income while sitting in A/C office and following instructions of manager/client.

Nothing wrong with that I am doing same. It is not a fault it is explicit choice they have made.

[girvo]

Well said. And they take like a duck to water when given the chance to do that novel creative tool driven work (and paid well).

Though in my direct example I’m talking about Malaysian outsourcing devs!

[whizzter]

You have some points but this scenario is also an industry symptom of what sloppy and/or inexperienced developers cause.

As an experienced developer being in this environment you have to be humble to the fact that money is still what rules interactions and apparent non-progress with vague promises can be seen from a _client_ perspective as no progress at all from seemingly total beginners.

Moving "fast" is often needed to assure people and for grunt-work it's absolutely fine as long as it doesn't build in bad requirements into the system...

And that brings us to the IMPORTANT point, moving fast gives you a good prototype ground and a chance to check assumptions with the client/end-users, but you need experienced people to put in brakes and remove bad assumptions out of the codebase before it leads to second-order bloat that makes the bad assumptions impossible to weed out.

In "enterprise" dev the core task that you don't want to hand off to juniors is often database models, data invariants, synchronization semantics,etc that inexperienced people will just try to paper over with increasing amounts of code when wrong and thereby creating huge swaths of code that just cements the bad assumptions into place and creates this glacial progress that you mentioned.