If you know aviation, literally anything that will decrease fuel usage. Also maintenance & repair operations (a whole lot of dirty fingerprints going on there).
This is changing somewhat at least in the airline world. Record profits have meant these companies finally have money to spend. Combined with iPads with ubiquitous connectivity a lot is changing.
The airline I work for is nearing a paperless cockpit. Flight attendants have handhelds loaded with tools for their job, credit card readers, and all of their manuals. Mechanics are joining soon with paperless aircraft logbooks, manuals, and line maintenance dispatching.
Almost all of this stuff is developed in-house or through contractors. It’s so customized to the existing data systems and airline operations that I don’t see how a SaaS could break into it. SaaS May work for smaller airlines who would be more willing to mold their operation to fit a tool.
As far as fuel usage goes that is unfortunately more a symptom of ATC. You can make the best flight profile in the world for fuel planning but as soon as ATC needs to change your profile it all goes out the window.
That's great to hear, been a while since I've been in the sector. As for breaking into it via a SaaS, it makes sense that they would build it themselves. Seems like operators all do the same thing but differently.
Not obviously, but it could be. Reducing idling time and improving routes both increase fuel efficiency without changing the airplane. Maybe software could help with those.
Edit: my reply was to the original comment which was something like "how is this a software problem?"
> Reducing idling time and improving routes both increase fuel efficiency without changing the airplane
Do you think idling time is a software problem? Aircraft idle for various time based on other requirements and needs, for example, spooling up the engines or inerting the fuel tanks.
Routes are already optimized by air traffic for the fastest, and cheapest route. They have no incentive to increase flight times as there would be fewer aircraft flying then.
Software can't fix aircraft idling, but maybe it can help. And ATC has the final say on routes for IFR aircraft (except emergencies), but there are a thousand VFR airplanes in the air right now. I think it's possible we can do better than GPS direct.
I don't have a solution for either of these things, just enough intuition as a pilot and software engineer to say "maybe there's something there".
Who knows. Most carriers fly the same aircraft from the same bases on the same routes with the same regulations. It's not because I know what it is, it's just one of the few areas with any scope to be a differentiator.
Convince regulators that advanced control techniques can be used on flight software (model-based predictive control, optimal control, etc.)
We know how to do these, maybe not as safe as we can with simpler methods today, but convincing the public and regulators will always be the challenge in aviation/aerospace.
Probably the only realistic (software related) method in today's world without a materials/battery improvement, but we won't get there for a while.
So I don't know the first thing about aircraft control, but I'm a control engineer by training.
What control scheme do aircraft use today? I always thought it was a form of MPC (well GPC = generalized predictive control) with a state estimator like a linear Kalman filter.
Are you familiar with DO-178? Basically outputs have to be deterministic.. so you can't really use advanced control techniques.
I haven't worked on flight control (but control on specific aircraft systems, which are at the same level), and they're all basically PID control thrown together.
Ah no, aircraft control is outside of my province, so this is new knowledge.
Advanced control can be deterministic -- through parameterization. Explicit MPC [1] does this. It pre-computes the quadratic optimization problem offline, so all the solutions are enumerated and stored, and are verifiable. However, as far as I know no one has implemented this commercially.
Interesting that it's all PID. Not surprised though because PID is tried-and-true (but even so, has a lot of tiny nuances which takes years to understand).
Thanks for the link, I was not familiar. I'm not sure if any current commercial systems use these methods.
I know the defense industry uses a lot of advanced techniques because they're their own regulators.
Should be usable in NetCoreApp 2.0 and up, or .NET full framework 4.6 and up. In other words, yes, it will work on recent versions of NetCore and classic .Net.
Software engineering can be reduced to math too, for example functional programming is a lambda calculus derivative. I think it's basically just that we're so close to programming that it's hard to see it for what it is, just a bunch of rules and equations.
That's just one facet of software engineering. Large swaths of it cannot be reduced to math ie everything the user actually sees, hears, perceives, etc. Those are subject to psychology, aesthetics, ergonomics ... Although we're trying to quantify those, too, so maybe one day ...
Giving up coding is what you do for your team, so they don't have to deal with the half finished B grade work you did inbetween doing the serious shit they can't do
Come on, there's no need to attack somebody like that just because your experience is different. Instead, share your experience so we can all learn from both sides. There isn't nearly enough information in seibelj's comment to draw a conclusion either way.
I have seen it too many times with project managers and now my CTO. Trying to still code and fix that terrible bug with already too little time. Ends up slowing down everyone because he never can get anything finished, or breaking things on a Thursday at 6:49pm because of the half baked solution he thought was good enough, but exploded in production, which he then has to spend 1 more hour fixing and 6 more hours cleaning up the aftermath. Spend your time reviewing and mentoring and try replacing yourself with someone who has time.
To be honest, you're not yet at the scale where this much of a concern. You're either "flat" and about to need to put in structure or you already have it. If you already have the structure in place, then you have at most 4 direct reports and at worst 2 (ideal team sizes being 3-5).
I say this not to downplay the work you've done, but instead to put it all in perspective. You're in the `11-50 Engineers: Clinging to coding.` stage.
I realise it might be shocking to hear but it's genuine and meant sincerely, I think you're probably making a mistake and because you are cto are not being picked up on it
Reporting hierarchy is there for a good reason. If you report to multiple people, you're the one that's going to have a bad time when they're not aligned with each other, each trying to give you a different list of priorities.
In a larger organization, "knowing what's important and what's not" at all times can be practically a full time job in and of itself. A lot of engineering teams like to protect individual developers from meetings and conference calls so they can focus on development, but that necessarily means developers will be missing context.
I think it's because it implies that their job is to report to you -like you're really the brains of the operation rather than just in a different role
I was recently reading that there are estimated to be 6 billion people in the world who want jobs, and estimated to be 2 billion jobs. So advice to "leave your employer" reflects a very narrow world view - a view from those having privilege, and without empathy for those with different choices.
