Alex, you are so funny!
440 karma · joined January 11, 2009
Noooooooo! sadface
Interestingly, this kind of mess probably keeps ~50% of us programmers employed. So ... yeh.
At RateIt we’re on a mission to redefine customer feedback - our core purpose is to give businesses the power to make every customer experience exceptional.
We build a multi-channel feedback capture platform that includes a mostly C#/.NET/Angular/SQL web stack and a Xamarin/Flutter mobile app. More details here https://jobs.lever.co/rateitapp/fde36142-6811-4e79-9871-0dd9...
I'd prefer senior devs but if you're passionate, or are hacking on your own projects in your own time, or have other experience in a largely remote startup product team I'd like to talk with you.
But yes, complexity is also a major problem.
Unfortunately.
But like the author said, the reuse fallacy prevents this from having a good RoI until there is a significant usage of said abstraction.
I'd be willing to bet there are engineers who are experiencing a lot of guilt about this right now. Not many.. but maybe even a handful. These are people who might not have been able to do anything about the problem had they realised the true scale of the risk. But I'd guarantee they exist, even if only in a number one can count on one hand.
It's a failing of the company culture where these engineers were not made safe to speak up; a missing facility for those who knew, to get the message to those who would do something about it had they known. It was likely a function of unhealthy (toxic?) company culture which precluded this psychological safety.
I bet these folks feel pretty bad.. maybe even responsible. They won't speak up tho, lest being labelled or even targeted with the full blame. They will suffer in silence, in some ways like the many soldiers ordered to do things they didn't think were right, but did anyway.
If you accept this, then the question might turn to how it was possible for the FAA to be weakened to such a degree that this corporate influence was possible. FAA are the regulator - at the end of the day, safety lies with them. Perhaps it's the responsibility of committee and congressional oversight to the aviation regulator? Perhaps the buck stops with the government representatives who have allowed this mess to be possible in the first place?
And if this can be traced to someone with influence, how was it possible for the company to be structured so that a single point of failure was possible - that speaks to a larger problem and then puts the senior exec on the chopping block too.
Maybe. But it won't be. That's not how corporate engineering works. And there's no appropriate pressure to change this. Boeing have far too much influence over the governing devices that are supposed to apply the healthy pressure which would result in the outcome you describe.
It can't incompetence because there will absolutely be engineers and designers who knew of the risks inherent to moving the CG and CoL and the deeper concerns of replacing these risks with a software solution (MCAS) which can relieve a human pilot of control. There is no way any self-respecting engineer with enough design influence would have been ignorant of the potential risks with this design.
It's probably not malice either because people generally aren't evil - especially those building planes which carry humans.
In saying that tho, there was almost certainly a "trade off" decision which was made, and thoroughly justified which traded safety for something else: most likely project delivery schedule. Was this motivated by economic reasons? Who knows. But the trade-off decision which sacrificed safety (even if in largely unknown, distant terms) would have definitely been there and was certainly a conscious decision. IMHO.
IMO, there would have been engineers and even some of the management chain who knew these risks, but for whatever reason, would have been pressured to make this go away. It seems like a conspiracist thing to say, but I've seen this in software engineering for years. There are heaps of perfectly legitimate pressures which will result in reduced quality and cutting of corners.. just in my work, lives are not at risk.
I will be surprised, if this vuln allows the attacker control outside of the WhatsApp app sandbox to other parts of iOS.
(I will be less surprised if the above is possible in Android)
Which brings be back to the original objection. I think this is true most of the time, except when it's not - which is your core Domain Model. The first 1/2 of the Blue Book[1] lays out straightforward means to arrange code, functions, data/state and related behaviours in a way which can be managed and maintained over time. This is pretty important as most folks who've spent any length of time maintaining vast applications will know that it's incredibly hard to reason about a first-class concept in an application without clear boundaries around said concept, it's structures and it's behaviour. Most of us are unlucky and find this scattered across the landscape. Few applications take the focus to "model" these concepts clearly.
Does this modelling have to be done with "Domain Model", or DDD, or something else that can be loosely coupled with OOD - probably not. But another developer absolutely has to be able to reason about said structures and behaviour. They have to be able to read it easily and grok it quickly. And having done that, they don't want to be surprised by some distant missing element, 20 calls or 1000 lines or 15 modules (repos, submodules, etc, etc) away! This is possibly the biggest time-sink and therefore "cost" of development. One could also take this further and postulate that about 1/2 of us are employed as a direct result of applications whose core concepts are so poorly designed or hard to reason about, that a massive volume of work (time?) is dedicated to unwinding the ambiguity that results.
I don't want to suggest that OOP or OOD/DDD/{other modelling process} would necessarily fix this, but the attempt to clarify and find a means to make modelling these critical concepts easier and less costly is admirable IMO.
It's ok if your infrastructure takes a different approach, or is "functional" or "dynamic" in nature. If your test suite uses completely different patterns and paradigms because the tooling makes that easy then - awesome! But if the core model/concepts of your application are hard to understand, reason about, and therefore maintain, then you're pretty fucked.
OO doesn't "suck". It's spirit is just largely lost and like many other things in life, it's been hijacked and mutilated into something many of us come to loathe because we've never seen it deliver on the promises. I guess we will be having this conversation again in another decade about something else that's hugely popular right now.
[1] https://www.amazon.com/Domain-Driven-Design-Tackling-Complex...
Plus this 4" form factor is magic.
* Refresh both http://www.avidaid.ca/ your websites with a modern feel http://www.avidaidmedia.ca/ Hire a designer for a fixed price on https://www.upwork.com/ or other freelancer site. Your potential employers will look you up and they don't want to find dated visuals like these. If you don't want to refresh the look of both sites, then take one down. An asset should make you look good, not detract from the perception it might create for you.
* Make sure your site(s) are HTTPS. Get on google and figure out how to do this (or pay the upwork freelancer to do it) and then it can be a talking point in an interview (how passionate you are about security and privacy, for example).
* Remove the word "President" from "President, Senior Project Manager and Consultant at Avidaid Inc." on your CV/linkedin. If you're going to a PM or consulting role then you have to have other roles which show you've done this recently. The "President" thing could work against you: "wow, this guy probably wants way more then we're prepared to pay"
* Maybe try dressing down just a tad - a some nice chinos or a collared shirt but not tucked in perhaps. I'm kinda spitballing here so just have a think about it. If the companies have heaps of younger folks then maybe you could do something to make them feel a little more comfortable in the interview. I personally know I'd be pretty intimidated if a candidate came in all suited up for a PM role. I'm not saying you want the "golf course" look. Just something a little more relaxed perhaps?
* Lastly, the "corporation" and "us" language on your website avidaid.ca is not going to work in your favour I don't think. Your linkedin https://www.linkedin.com/in/dwimsett/ and the tired website suggest there are heaps of folks working at your consultancy. I can only assume this is a false pretence given the CBC article. I would prefer to see a portfolio which talks about "you"!!! (personally) and highlights projects, interactions and specific work-related interests which you are likely to be passionate about. This will excite me as a hiring manager.
I hope this helps mate.