Only it isn't specific. Thats the point. The same neural net approach is being used in multiple domains. It exhibits the same kind of robustness that we do. Sure, we are not there yet, but if you look at the rate of progress it is evident that we are at most two or three doubling away from general purpose intelligence in machines, This means four to six years away. One hundred years? Not a chance. The chance of having genuine universal AI within ten years is about 90%.

And even if the technology progress stagnated, as can happen in technological progress, the AI we have right now is already at the point it can drive a car and perform many jobs we think of as the domain of humans. What we do not have right now is a serious effort to identify an alternate economic model which accounts for this. There is the universal income, but there has been no detailed analysis of various economic models. It is all very well stating the obvious; that the machines are coming, but the hard questions really remain open. How should we adapt?

I can't say this is terribly helpful advice. The problem is that all companies are dysfunctional in some way. The problem as described is very common. As a professional software developer it might be a good idea to actually provide solid professional advice on proven ways of extraction from these nasty anti-patterns. We all live in a society where there are ignorant, selfish, mean and frankly stupid people around you every day. Your only real decision is how you will deal with it.

Will you cut and run the instant you are in a difficult situation that isn't perfect? How boring is that? I would rather join a company which is has dysfunction, has problems, but at least has people self aware enough to listen. I have found most managers are prepared to listen. You can join a company and provide the guidance to work better. Not right away of course, that would be rather arrogant, but once you find your feet and understand how it works you can provide advice and perspective. And even when there are areas that cannot change you would be surprised what you can achieve without formal permission.

This is of course a well known problem documented in the paper Big Ball of Mud by Brian Foote:http://www.laputan.org/mud/. The basic problem is that many systems grow organically as new features are required, but as new features are added to the system it becomes more complex and tightly coupled. Another aspect I have noticed might be the 'Black Hole' syndrome. In systems that are custom written and business critical there is no clear scope of the project. With no clear scope anything new that the business needs is simply thrown into the existing system. The never ending scope creep means that the system takes more and more responsibility. And so grows a monolithic tightly coupled black hole. Because it is at the centre it tends to attract any new requirements because anything new needs to interact with it. And the more you add the harder it is and the more bugs you introduce.

There are well known solutions of course. The first would be to read the link above. However, there are two broad areas to address, and you need business buy in for both. The first is software development discipline; proper code repositories, regular check in, unit tests, code reviews. And while there should be nothing new here there is often resistance from management. You need to explain to management that poor quality means lower development velocity. Taking time to do testing and code reviews may appear to take time, but try not doing it and you find out pretty quickly the folly of ignoring quality. This is just basic coding hygiene. You can of course also apply agile principles and practises, such as time boxing of iterations and regular feedback from users.

But okay, you have an existing system you need to fix. Service Oriented Architecture is more than just a buzzword; it is the principle of separation of concerns. First thing to do is define what the system does. Does it do multiple things? You need to have a clear idea about what the system does, and to then begin to cleave them into separate systems with clearly defines scopes. Sometimes this means identifying relatively simple subsystems to separate. Break the system apart and introduce well defined contracts.

Refactoring code without getting a eagles eye view of the whole system and where to introduce the interfaces is dangerous. Often this process of architectural clarification can cause systems to experience complexity collapse as duplicate code is reduced and removed. Premature re-factoring at the class level may introduce little benefit. Better to pull off the small subsystems with a clear scope and purpose and ensure the code in these new subsystems do not include unnecessary external domain objects.

Again, without having the business behind you a project like this is doomed. You need to present a clear plan to the business and explain how it will improve quality and the ability to add new features, while reducing development costs. You need to explain that this is not a issue with the quality of software developers, but rather a systemic problem that can be corrected. And of course for this you need someone with the courage to tell this story in a compelling way.

The suggestion that Snowden, in revealing the illegal practises of the US Government is somehow responsible for ISIS carrying out the Paris attack is patently ludicrous.

But perhaps those making the accusations are trying to deflect their own responsibility? ISIS were established, at least originally, by Sunni Muslims from Iraq who had been alienated and excluded from the political process in Iraq. Without the Iraqi invasion ISIS would not exist. Didn't stop there either. In the attempt to supply the Syrian Free Army, which was in fact a number of groups including those who would become ISIS, with weapons and aid the Americans had not only given them fertile ground to harvest, but given them the tractors and machines to till the soil.

And now the Americans complain that Putin is fighting the enemy of Assad; which is ISIS. ISIS for their part took the opportunity to take poorly defended US military equipment in Northern Iraq. Those fighting ISIS in Northern Iraq, the Kurds, have been given little support, and continue to be attacked by US ally Turkey. So how, given the facts on the ground, can the US in all seriousness try to condemn others for assisting ISIS, when without the US they would not exist?

I am not saying the US has made ISIS do what they have. The reprehensible attacks across the world are the behaviours of morally vapid thugs who are totally responsible for their actions. Make no mistake that I have no sympathy for them. But the US cannot wash its hands of the part it has played, once again, in enabling this kind of tyrannical villainy.

The word 'proper' is a trigger word for me . So lets talk about requirements gathering; what is 'proper' requirements gathering? How much detail do you need to get for it to be good enough?

Requirements are like measuring the perimeter of a country; the shorter your ruler the longer it is, the more curls and crannies you find. And so it is with requirements; the more detail you get into the more you find. But there is a point at which the requirements become the application. There is a point where the process of examination of the problem to find what is needed explores the design, where screens are designed, data structures determined, reports specified.

With agile you realise that development is a process of navigating a virtual space of possible applications. Your strategy is to use evolutionary processes to navigate towards the solution needed based on the fitness function of meeting the users real need. If you go to a user with a blank sheet of paper how can they know what they will need in detail? They don't really know. The process of finding out what they need is design.

With Agile the requirements are limited to statements that the user can express; very high level and general. They are place holders for a more in depth exploration and feedback. And so we get to the most critical aspect: feedback. Without a feedback cycle and iteration the software does not evolve. The waterfall style development processes inevitably turn into ad hoc evolutionary projects. The difference with Agile is that we are honest; we don't try to say we can know more than we do, or have some magical power to get perfect requirements before starting. We put our ego on the shelf and acknowledge that there are no perfect requirements, no perfect designs, no perfect code. We place evolutionary principles such as short iteration cycles, regular user feedback, and unit testing at the centre of our approach,

Yeah - this. change, adaptation and innovation are part of the game. Getting stuck in the same position, using the same technology on the same project is boring, unfulfilling and ultimately dangerous for developers. You can't know all the technologies, but you should keep an eye on technology and learn to use the ones that can really be beneficial. Not always easy. But if you are a Cobol programmer you might still be able to learn a living, but it will not be developing exciting new applications. If anything my focus has changed; to value human aspects over technology. Really great things happen when you have the right people with ownership and pride in what they do, working as an effective team. New technology is easy. People are hard.

If developers are using Agile as an excuse for skipping QA you are doing it wrong. Agile is not simply breaking a project into mini milestones and working through them. Once again we see people seeing the process as a excuse for failing to think.

So, Agile is about Adaptability. It is about evolution. This means creating a feedback cycle to deliver real verifiable business value every single iteration. If the work doesn't pass QA, if it doesn't actually work, then IT HAS NO VALUE.

Agile is a evolutionary approach in which there is a tight feedback between customer/user and developer, where there is strong feedback and testing again the fitness function of customer expectations.

Actually not. Aircraft would not simply follow ATC instruction. They would use TCAS and TAWS to ensure that the aircraft did not fly into terrain or other aircraft. It would also ensure a proper approach and landing. There should be no way to send external commands to an aircraft to cause it to crash. The onboard computers should take the same position as a pilot; responsible for the safety of the passengers. If ATC gave instructions to fly into a mountain to a human pilot they wouldn't do it, and neither should a machine piloted aircraft.

While this may appear looney at first the reality is that flight control systems usually run the flight anyway. The reason we have pilots relates moe to the voice communications required to interface with ATC these days. Once you have a secure way to communicate between ATC and aircraft digitally you will be able to automate airspace. Suddenly rather than having to allow UAV's into the airspace most aircraft will be a UAV in the sense they have no pilot.
Also, even if you allow the pilot to stay, they should not be able to fly it into terrain. There are TCAS and TAWS systems already of course, but even a simple GPS and Google Earth terrain data would be able to be used to create a flight controller which refuses to fly into terrain. And I don't mean that pilot suicide occurs very much at all; small aircraft often fly into terrain. A cheap, effective, reliable flight control system for small aircraft would be a great advance for safety.
That doesn't mean we take away the ability to manually pilot; just have a backup which will initially advise, then warn, and perhaps even take control to avoid a collision with the ground or other aircraft. This is what will be needed for UAV anyway.

The Immortals will rise, and they will put the coders out of work.

But not before the rest of you.

Mwha hahaha.

It's a Cookbook!

The whole deal with CAA restricting your work is BS. You are free to fly what you like just by flying out of a farmers field more than 4km from a airfield. Does your system even compare to ADS-B? Small Linux computers can easily be used to receive ADS-B, and I expect they will be built into Quads and other hooby size aircraft soon. This way they will be able to avoid traffic long before it gets within 1.5km.
I am confident that CAA understand the issues. They have just released draft legislation which you obviously have not read yet, because if you had you would know that they are introducing a way of applying for permission to operate UAVs outside the hobby provisions. They are also going to remove the hobby references. I suggest you look it up and have a read.
What this new legislation will not do is integrate UAVs into normal airspace, and frankly until there is a reliable sense and avoid this is a position I support. Too many idiots out there who have little or no training flying Quads into controlled airspace. There needs to be real, reliable solutions for sense and avoid and technical enforcement of airspace before we open the integration door.
Frankly your hostile morally superior approach is not helping. The CAA has been very interested in an open conversation, and has listened to the community to come up with some regulations which are moving in the right direction. They have not addressed how to integrate airspace at this point, but they are not at all unreasonable. They are tasked with keeping the flying public safe, that must be the first priority.
I will be working on a proof of concept system which uses passive ADS-B for sense and avoid. This can detect aircraft potentially hundreds of kilometers away with precision. I also plan to extend the geo-fence system to ensure UAVs stays outside of controlled airspace and clear of terrain.

There is a strange middle ground of a sort. I am not invested too much in the outcome. Some people shrink from the fight because victory is impossible. This is the 'pragmitist' who evaluates the probability of success and decides the low chance of success means the goal itself isn't worth the effort. Then there are the optimists who fool themselves that the goal is easier than it is, or who believe that the good guy always wins. This is delusional.

Then there are people who accept the reality: they know the road will be hard, and long, involve personal sacrifice and perhaps suffering. They will not fool themselves about the ease of the goal or the probability of success. In fact in many ways the success or failure is deeply irrelevant because as I said above all we have is our intentions and actions. Do or do not, that is our choice. The outcome is up to fate and should not concern us.

This is what Stockdale meant; that we should not fool ourselves about the ease of the goal; that we should face up to grim reality and conduct ourselves in a way that best reflects on us. Because nothing else matters.

It is this attitude that drove my involvement in the campaign against Software Patents in New Zealand. A campaign that was always one breath away from failure. A campaign that many concluded was doomed to fail. A campaign that despite being passed into law may be swept away by the TPP. But these threats do not worry me because so long as I am prepared to stand up and work for the common good I honour myself regardless of the outcome.

I think you have discovered for yourself the way to being content then is not to judge. The control I am talking about is the ability to do as you suggest; to not hold expectations or judgements. The externals are indifferent to you because you have no control over them. The only thing you have control over is your intentions and actions. Therefore the only thing you should be concerned about is how you honour yourself through your actions.

I did not mean control over your physical body; health or the lack of it, while somewhat able to be influenced, is also largely outside you control and ultimately futile. The only thing that can truely be said as your own is your thoughts and actions.

'Positive thinking' is essentially the vein hope that the current situation you judge as undesirable will change to something desirable just because you desire it. It fails to recognise that being happy and content can be achieved simply by changing your judgement. You can decide to be content with your life. The truth is that those external things; wealth, health, power and fame, are all fleeting. The only thing you really have control over is you. The solution isn't hoping that things will get better, it is accepting that they won't and pleasantly surprised if they do.