>> If something really is unnecessarily complex, better alternatives are likely to arise, perhaps suddenly. (This assumes people are free to choose alternatives, not prohibited by law, for example.)<p>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.<p>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.
It's unethical to inflict "needlessly hard" technologies on a client who isn't using them already. But an enormous fraction of the world's valuable, productive software is both needlessly complex and built using (arguably) obsolete tools and frameworks.<p>The are good <i>career</i> 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.<p>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.
I often find people are a lot more focused on the technology than on actually solving problems. As well as having a flashy POC for the sales team I'm all for having a dead simple but working shell of app with no polish.
What he's missing here is that this is a great strategy for any tech that will be hard to get rid of. Overly complex tech strongly integrated with businesses internal apps and procedures rarely disappear when something better comes along. Name a major company supplying enterprise software and there's probably better stuff. You don't see everyone flocking to it.<p>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. ;)<p>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 have heard from a colleague that he has a friend who is an exceptional SharePoint expert and loathes it because of its complexity. Multiple times he flew to client locations around the US and changed a single line of code and got paid $$$ it.
>> If something really is unnecessarily complex, better alternatives are likely to arise, perhaps suddenly.<p>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.<p>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:<p>>> That sounds like an unpleasant way to earn a living.
I long for the day PDF is finally expunged from the technical environment, in the meantime people still like to generate documents with it; and even with the variety of toolkits, frameworks and APIs, there's still a bit of knowledge needed to work with them efficiently.<p>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.
Good ol' accidental complexity and essential complexity.<p>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.
Perhaps what is "needlessly" hard (whatever that really means) to one is the exact right solution for someone else?<p>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.<p>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.<p>Aren't most of us interested in making (more) money?<p>It would be nice to know of what he is speaking of.
Made me think of INTERCAL: <a href="https://en.wikipedia.org/wiki/INTERCAL" rel="nofollow">https://en.wikipedia.org/wiki/INTERCAL</a>
Seems to work well for SAP. I also have a suspicion that for example Java is so complicated because it was created by a consulting company - complex tech means high paid consultants.