If I had a dollar for every time I've heard the phrase "XXX is a solved problem," indicating that there's a dependency that "solves" it, I'd be rich.
People think that, just because we can google up a dependency that does what we want (sorta/kinda/mostly), the "problem is solved."
It's been my experience, that, when our "solution" is to bring in a massive dependency to address a very basic issue that we could solve, ourselves, by banging out a bit of code in a day or two, our problems are just beginning. In some cases, that's exactly what I have done. For example, I use dependencies to handle SOAP (yuck), for ONVIF work, and keychain access for login Face/TouchID validation. These are small, atomic dependencies, written and maintained by reputable authors. The SOAP thing would have taken me a couple of months to write something not as good, but the keychain thing is something I could write, myself, in a couple of days. I just find that I don't really need to, as there is an acceptable alternative.
In fact, when I have been dissatisfied with the choices, and have decided to write my own solutions, I have encountered derision.
I feel for the OP, but I am sad to hear they are leaving the industry. Maybe it's for the best, or maybe they will always look back in regret.
In my case, I have just realized that I can't look to others to validate my work, and have to work on my own. It is not my preferred choice. I worked on (often, huge) teams, my entire career. But I won't compromise my personal ethos to be "down with the kids." If writing good software is no longer in fashion, I guess I'll be unfashionable. I won't deliberately write bad software. I couldn't live with myself.
For me, I'm never leaving, but that may mean that I'll need to work on my own. I have a pretty good record of creating stuff that other people value, so we'll see how that goes.
You don't need couple of months to implement SOAP, unless you want to make a framework. SOAP is just an XML passed via HTTP. You can build everything from the ground up in a matter of few days. And if you can re-use any HTTP library and XML parser, it's a matter of few hours.
May be there's some layer above SOAP which requires more implementation. I have no idea about OVNIF. But SOAP itself is pretty simple. Basically you're firing SoapUI, figuring out protocol details and write code to deal with that particular XML-based format.
Thanks for that. I based my estimate, looking at the code for SOAPEngine[0], which is the library I use. It's pretty complete, and that guy knows his stuff.
I tend to be fairly anal about testing; especially low-level stuff. It can be a bit excruciating, working with me, as I insist on pounding away at everything. That's why it's taken a week and a half to get to the place I'm at now. I'm working on the login and initial user edit stuff. Basic (but critical) stuff, and I keep encountering edge cases. I'm also debugging the backend SDK.
If I had a dollar for every time I've heard the phrase "XXX is a solved problem," indicating that there's a dependency that "solves" it, I'd be rich.
People think that, just because we can google up a dependency that does what we want (sorta/kinda/mostly), the "problem is solved."
It's been my experience, that, when our "solution" is to bring in a massive dependency to address a very basic issue that we could solve, ourselves, by banging out a bit of code in a day or two, our problems are just beginning. In some cases, that's exactly what I have done. For example, I use dependencies to handle SOAP (yuck), for ONVIF work, and keychain access for login Face/TouchID validation. These are small, atomic dependencies, written and maintained by reputable authors. The SOAP thing would have taken me a couple of months to write something not as good, but the keychain thing is something I could write, myself, in a couple of days. I just find that I don't really need to, as there is an acceptable alternative.
In fact, when I have been dissatisfied with the choices, and have decided to write my own solutions, I have encountered derision.
I feel for the OP, but I am sad to hear they are leaving the industry. Maybe it's for the best, or maybe they will always look back in regret.
In my case, I have just realized that I can't look to others to validate my work, and have to work on my own. It is not my preferred choice. I worked on (often, huge) teams, my entire career. But I won't compromise my personal ethos to be "down with the kids." If writing good software is no longer in fashion, I guess I'll be unfashionable. I won't deliberately write bad software. I couldn't live with myself.
For me, I'm never leaving, but that may mean that I'll need to work on my own. I have a pretty good record of creating stuff that other people value, so we'll see how that goes.
More will be revealed...