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.
I don't think Java the language is particularly complicated - it has a much simpler core than C++, which it sort of superseded in a lot of areas. People went a little nuts with the XML and ObjectBuilderFactoryFactory nonsense and all of the "enterprise" stuff, but you could create similar levels of insanity in any programming language, if the fad storm hits.
Learning (needlessly) hard technology
41–50 of 55 posts
Re: Learning (needlessly) hard technology
#42>> If something really is unnecessarily complex, better alternatives are likely to arise, perhaps suddenly. 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/r…
Oh they are. No need to wonder.
Re: Learning (needlessly) hard technology
#43Earlier quoted context omitted.
I've had to face the most horrible people with the most horrible requests.One of them being a request to "Send a payload with a Get request" . I spent nearly 2 months of my life convincing them this was not possible.I understand maintaining a high quality of code.But a major part of the reason for using archaic/available-for-the-past-10-years technology is 2 fold: 1.The HPBs do not want to/cannot learn anything new l…
> One of them being a request to "Send a payload with a Get request" . I spent nearly 2 months of my life convincing them this was not possible 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…
[1]:http://www.w3.org/TR/XMLHttpRequest/#dom-xmlhttprequest-send
Re: Learning (needlessly) hard technology
#44Earlier quoted context omitted.
I've had to face the most horrible people with the most horrible requests.One of them being a request to "Send a payload with a Get request" . I spent nearly 2 months of my life convincing them this was not possible.I understand maintaining a high quality of code.But a major part of the reason for using archaic/available-for-the-past-10-years technology is 2 fold: 1.The HPBs do not want to/cannot learn anything new l…
> One of them being a request to "Send a payload with a Get request" . I spent nearly 2 months of my life convincing them this was not possible 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…
Because that would be an easy place to send data.
Re: Learning (needlessly) hard technology
#45Earlier quoted context omitted.
I've had to face the most horrible people with the most horrible requests.One of them being a request to "Send a payload with a Get request" . I spent nearly 2 months of my life convincing them this was not possible.I understand maintaining a high quality of code.But a major part of the reason for using archaic/available-for-the-past-10-years technology is 2 fold: 1.The HPBs do not want to/cannot learn anything new l…
> One of them being a request to "Send a payload with a Get request" . I spent nearly 2 months of my life convincing them this was not possible 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…
To summarize: You do not need to always rebuild or always stay with legacy code.You need to adapt and determine where would you spend more of your development effort.I cannot spend 80% of my time solving problems that the world has already solved
Re: Learning (needlessly) hard technology
#46Earlier quoted context omitted.
> One of them being a request to "Send a payload with a Get request" . I spent nearly 2 months of my life convincing them this was not possible 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…
But the AJAX spec says that if the the request type is GET,the body/data is set to null[1] or am I reading it wrong. [1]: http://www.w3.org/TR/XMLHttpRequest/#dom-xmlhttprequest-send
Edit: Of course this isn't recommended, but I think the time wasted trying to convince the (seemingly terrible) manager could have been better spent.
[0] http://www.boutell.com/newfaq/misc/urllength.html
Re: Learning (needlessly) hard technology
#47Perhaps what is "needlessly" hard (whatever that really means) to one is the exact right solution for someone else? 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 coul…
> Perhaps what is "needlessly" hard (whatever that really means) to one is the exact right solution for someone else? 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.
Re: Learning (needlessly) hard technology
#48Good ol' accidental complexity and essential complexity. 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.
It's not always "no reason." 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 st…
Re: Learning (needlessly) hard technology
#49The 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.
Re: Learning (needlessly) hard technology
#50Seems 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.