The thing that worries me most is that, based on mere amateur observations in the media, the number of incidents involving user interfaces, repeated changes to procedures, and software fixes to "unexpected" corner-cases seems to have been in the increase.
To the uninitiated, it seems that problems in airline incidents used to revolve around mechanical failures, bad wiring, sensor malfunctions, toasted electronics causing smell of smoke and such. Plain and simple. Issue a fix in the design and apply to all planes of the same type, and you'll end up reducing the failure surface bit by bit.
I might be totally wrong about this because I don't track actual data. But if I've spotted the trend right it's scary because the problems are shifting into our space, i.e. software engineering. And being a software engineer, I know we're pretty much fucked at that point. We've only ever managed to write reliable and trustworthy software when we've split it into very tiny pieces that we can verify and kept the number of pieces small.
Maybe aviation computers used to be much simpler that they could be verified more throughoutly. Maybe airplanes used to have less features and they could keep the complexity sufficiently down and functionality orthogonal. Maybe there was enough human glue in between the systems so that there was a live sanity-check during flights and pilots could react properly if the computers didn't agree on something.
But now I sense a new category of error conditions that are eerily similar to what we've had in non-critical software for decades where assumptions are laid on top of other assumptions, and when they fail the whole stack comes crashing down. Only this time there might be a whole plane coming down instead of getting a curious SIGSEGV on the screen with a blinking cursor. It might start as an innocent "couldn't access flight plan because of wifi went down" but such interdependencies between certified and uncertified systems grow exponentially and this will snowball into the unmanageable very soon.