Not being free to pick alternatives is a common case. There are a lot of dev teams out there that have "approved technology lists". What gets on this list is decided by management and/or a lead architect. It can often be the case that simpler alternatives can't get used because they aren't approved.
This isn't necessarily a bad thing. I could see project management saying "no" to simpler solutions in the name of preserving the stability of a project. Besides, a sufficiently talented team should be able to work within such resource constraints and come up with creative solutions anyways.
Another third situation that I would agree with: Clients sometimes really do not like to trust new technology.An age old anecdote is always brought ; "Why fix what is working?"
I assume you know it really is possible, right? (in URL parameters - with certain limitations about size if I remember correctly... or did just IE choke at 2048 bytes? I forget...) I am not arguing you should use GET instead of what should clearly be a POST, but saying it is not possible is IMHO misleading. And there are sometimes valid business reasons to use (invalid) technical solutions.
I understand your point, but neither extreme (always staying with legacy / always rebuilding) is particularly good.
The are good career reasons to think long and hard before specializing in this stuff. After all, once you go too far down the rabbit hole, you may not be able to climb back out, and nobody wants to be a 35-year-old developer with a completely obsolete skill set.
But if you're a 55-year-old consultant, you may be planning to retire long before the systems you're working on disappear. In this case, I can't see anything wrong with specializing in ugly, valuable dinosaurs that nobody else wants to get near. Under the right circumstances, I've heard of this work paying $350/hour and up.
Exactly
Also you spent time learning something completely unusable beyond a certain niche, that usually does not transport anywhere back to "sanity land"
I'm strongly opposed learning something that will be good for nothing beyond actually making the wheels of bureaucracy and/or legacy turn
The concept is called lock-in. One can build a career strategy on it if done right. Just ask all the people working 9a-5p getting paid a premium to do SAP, legacy Microsoft, Oracle, COBOL on IBM mainframes, pipelines between legacy data sources/consumers, and so on. Some of this gets hit by outsourcing but many jobs remain. And one can always start an outsourcing consultancy with in-country, priority support or services. ;)
So, it's a valid approach that's working out for many much better than alternatives which require dozens of constantly changing skills and high layoff risks due to being replaceable & easy to automate. I'm not saying it's the best or lowest risk approach. You'll probably hate the career unless you see work as a means to an end to have fun in spare time. It's got lots of potential though.
I suspect that a good majority of corporate code assets trend toward becoming unnecessarily complex. After a certain level of complexity is reached, a company will often look for that better alternative and decide to rewrite from scratch. But in many/most cases of this that I know of, this attempt to recreate/rebuild is found to be intractable.
What seems to happen is that more and more developers are hired to maintain the complexity and I wonder if that's what most developers out there are doing, maintaining complexity, which always makes me think the same thing:
>> That sounds like an unpleasant way to earn a living.
Oh they are. No need to wonder.
I don't sell myself as a PDF expert, but my level of knowledge and experience is high enough that I can maintain and improve systems and workflows tightly bound to them. I keep it on my resume, but have no desire to mine that resource for fear of being the canary.
There's a nontrivial amount of technologies that are complex and otherwise byzantine for no reason. Given the lack of alternatives, knowing the arcane tech inside and out can provide for a sustained stream of money, but that's hardly ethical.
Back the 1990s, GNU autoconf looked like a miracle to me, and in fact, back then you got better results compiling from source than you got using what passed for a package manager.
These days people complain that autoconf is too complicated, being a bunch of shell scripts on top of shell scripts compiled with M4.
Then there is SAP, which stands alone in its ability to destroy value. SAP started out as a mainframe application, got ported to Unix in the 1990s (not many succeeded at that) and now they want you to run it on an in memory database for which you can't afford the hardware, never mind the software.
Anyway, I can hardly think of a dumber way to spend my oh-so-valuable time then to spend it on learning a tech just because its "needlessly" hard (yes I know I'm overusing the parenthetical, for effect of course), but to each their own.
To be honest, learning it as a strategy to bump up one's rates could be considered a rather smart thing to do, but of course you had better understand the true economics of the move and know thy markets.
Aren't most of us interested in making (more) money?
It would be nice to know of what he is speaking of.
Trying to be everything to everyone is one of the surest ways I know to generate byzantine monstrosities. On the other hand, it takes some real nerve and discipline to tell 'No, that is not really what our product is about' to a paying customer.
It takes good engineering, and you still won't be able to say yes for every request (for lack of time if no other reason), but it does not require your product to be needlessly hard to use.
It's also not for every product. I just wanted to point that exceptions exist.
The main school of thought in business these days is still organizational and process focused. Only the newer guys think of business in terms of products, SOAs, SDGs and APIs, and it'll take decades yet for that kind of thinking to fully infect corporate America.
It gets unwieldy if you try to build complex data structures, because you literally have to do everything the compiler would usually do. So if you're trying to build an incredibly complex machine with lots of objects and interfaces, it will take you a very long time.
Java is complicated because the culture is complicated. It's not just a language - it's a set of architectural practices and expectations, some of which are questionable, combined with a unfeasibly large ecosystem of libraries and add-ons.
So it's easy to learn the basics, but it's not so easy to get to the point where you can start producing high-quality maintainable code within a typical working context.
Assembler is simple like lego is simple: the basics are tremendously easy to understand but the distance between the basic elements and the problems you're trying to solve is very large.
The more 'batteries included' something is the more time you'll spend learning about the eco-system and less about the language per-se.
