Small suggestion. Don't choose obscure language (in terms of popularity, 28th on TIOBE index with 0.65% rating) to visualize structure and algorithms. Otherwise you risk average viewer will stop reading the moment he encounter code samples.
There are 27 more popular languages, some of them orders of magnitute more.
UK air traffic control meltdown
41–50 of 459 posts
Re: UK air traffic control meltdown
#42I imagine, for this kind of system, there is only one supplier. Why not force that supplier, as part of their 10-15 yr contract, to publish the source code for everything, not necessarily as FOSS. This way if there are bugs they can be reported and fixed.
Re: UK air traffic control meltdown
#43Small suggestion. Don't choose obscure language (in terms of popularity, 28th on TIOBE index with 0.65% rating) to visualize structure and algorithms. Otherwise you risk average viewer will stop reading the moment he encounter code samples. There are 27 more popular languages, some of them orders of magnitute more.
Maybe he doesn’t care if people stop reading and he’d prefer to use the language he’s most comfortable with? It’s his blog after all, not yours.
Additionally, perhaps he’s making the point that a language with an expressive type system makes solving problems like this trivial.
Re: UK air traffic control meltdown
#44Small suggestion. Don't choose obscure language (in terms of popularity, 28th on TIOBE index with 0.65% rating) to visualize structure and algorithms. Otherwise you risk average viewer will stop reading the moment he encounter code samples. There are 27 more popular languages, some of them orders of magnitute more.
The code is a relatively small part of the article, and quite far into it I might add.
Re: UK air traffic control meltdown
#45Software has bugs, that's not really the damning part... The damning part is that in four hours and two levels of support teams, there was noone who actually knew anything about how the system worked who could remove the problematic flight plan so that the rest of the system could continue operating! What exactly is the point of these support teams when they can't fix the most basic failure mode (a single bad input..…
Just guessing: They bought a software from a third party and treat it as a "black box". There are few known ways that the software fails, and the local team has instructions on how to fix it. But if it fails in an unexpected way, good luck, it's impossible for the local team to identify and fix the problem without the vendor. The reason it took so much was they realized too late that they need to call the vendor. Pro…
Considering this same failure has happened a few times in recent memory maybe its over optimistic of me to expect an entry on the support wiki or something.
Re: UK air traffic control meltdown
#46I imagine, for this kind of system, there is only one supplier. Why not force that supplier, as part of their 10-15 yr contract, to publish the source code for everything, not necessarily as FOSS. This way if there are bugs they can be reported and fixed.
I agree. But this would assume that:
1- the people writing and approving the specs even understand why this might be a good suggestion
2- the people ultimately approving the contract aren't in bed with the supplier
Re: UK air traffic control meltdown
#47Small suggestion. Don't choose obscure language (in terms of popularity, 28th on TIOBE index with 0.65% rating) to visualize structure and algorithms. Otherwise you risk average viewer will stop reading the moment he encounter code samples. There are 27 more popular languages, some of them orders of magnitute more.
I appreciated the Haskell examples, they aren't particularly hard to follow. How do you think those more popular languages got more popular?
Re: UK air traffic control meltdown
#48This is one of the many reasons there should be a universal data standard using a format like JSON. Heavily structured, easy to parse, easy to debug. What you lose in footprint (i.e., more disk space), you gain in system stability. Imagine a world where everybody uses JSON and if they offer an API, you can just consume the data without a bunch of hoop jumping. Failures like this would vanish overnight.
Broadly speaking I think this is done for new systems. What you need to identify here is how and when you transition legacy systems to this new better standard of practice.
I'd argue in favor of at least an annual review process. Have a dedicated "feature freeze, emergencies only" period where you evaluate your existing data structures and queue up any necessary work. The only real hang up here is one of bad management.
In terms of how, it's really just a question of Schema A to Schema B mapping. Have a small team responsible for collection/organization of all the possible schemas and then another small team responsible for writing the mapping functions to transition existing data.
It would require will/force. Ideally, too, jobs of those responsible would be dependent on completion of the task so you couldn't just kick the can. You either do it and do it correctly or you're shopping your resume around.
Re: UK air traffic control meltdown
#49Small suggestion. Don't choose obscure language (in terms of popularity, 28th on TIOBE index with 0.65% rating) to visualize structure and algorithms. Otherwise you risk average viewer will stop reading the moment he encounter code samples. There are 27 more popular languages, some of them orders of magnitute more.
Maybe he doesn’t care if people stop reading and he’d prefer to use the language he’s most comfortable with? It’s his blog after all, not yours. Additionally, perhaps he’s making the point that a language with an expressive type system makes solving problems like this trivial.
If you don't care about readers reading it or not then what is the point to publish an article ?
Re: UK air traffic control meltdown
#50And why could the system not put the failed flight plan in a queue for human review and just keep on working for the rest of the flights? I think the lack of that “feature” is what I find so boggling.
To be fair, the article suggests early on that sometimes these plans are being processed for flights already in the air (although at least 4 hours away from the UK). If you can stop the specific problematic plane taking off then keeping the system running is fine, but once you have a flight in the air it's a different game. It's not totally unreasonable to say "we have an aircraft en route to enter UK airspace and we…
> "we have an aircraft en route to enter UK airspace and we don't know when or where - stop planning more flights until we know where that plane is".
Flight plans don't tell where the plane is. Where is this assumption coming from?