Agile Development

I have been reading about Agile Development, a method designed for software development, and wondered if it is a technique that could be applied to hardware, defence hardware.

Agile Development is like many approaches to complex problems, an amalgamation of various ideas and processes developed over time. It came together in early 2001 and was defined by 12 basic principles.

  1. Customer satisfaction by early and continuous delivery of useful software
  2. Welcome changing requirements, even late in development
  3. Working software is delivered frequently (weeks rather than months)
  4. Close, daily cooperation between business people and developers
  5. Projects are built around motivated individuals, who should be trusted
  6. Face-to-face conversation is the best form of communication (co-location)
  7. Working software is the principal measure of progress
  8. Sustainable development, able to maintain a constant pace
  9. Continuous attention to technical excellence and good design
  10. Simplicity—the art of maximizing the amount of work not done—is essential
  11. Self-organizing teams
  12. Regular adaptation to changing circumstance

Wikipedia has a very good overview, click here to read.

Other similar processes have evolved, Scrum and Extreme Programming for example, but they are variations on the same iterative test as you go process.

Simplistic answers to complex problems are usually illusory but would it be worthwhile to test some of the principles on a smaller defence project to see if any of the principle might deliver some benefit to the defence acquisition process.

I particularly like the principle of requirements developing over time and finding a way to manage this. If we look at FRES for example, this is exactly what happened, it is just that we didn’t manage them very well!

With defence equipment development, the user defines the requirement at the beginning of the CADMID acquisition process with the User Requirement Document. Some trade-offs do occur during the concept and assessment phases but in general, the requirements stay relatively static (stand fast CVF)

I am drawn to Textron’s approach to the development of the Scorpion combat aircraft. Textron took an idea to a flying aircraft in two years, with no external support and with its own cash, reportedly in the ‘tends of millions’ of Dollars.


Textron concentrated on getting the right people, insisting on face to face communications within a self-organising team, a couple of principles straight out of the Agile Development rule book.

At the peak, Textron only had a couple of hundred people working on the project, rapid decision making was achieved and the results speak for themselves.

For developing a DOD (Department of Defense) aircraft, it was completely radical. The traditional way a military aircraft gets developed is the DOD, or one of the services, they sit down and write out all the requirements they want. Hundreds of pages, detailed requirements. We completely threw that away because we’d still be here trading paper back and forth if that was the route we were going to take.

Textron built a set of requirements but they evolved them over the course of project and whilst much is made of the re-use of existing components the real achievement was the process.

Whether it is a success or a flop, the process used to get it flying was, and is, impressive as hell.

The Urgent Operational Requirement (UOR) could be seen as an agile process but in general, it takes MOTS or COTS equipment and doesn’t develop anything. A hybrid UOR/CADMID project was the Foxhound Light Protected Patrol Vehicle. It was bought into service very quickly but no corners were cut.

Chris Maughan, Managing Consultant at Decision Analysis Services Ltd wrote an excellent analysis of the Foxhound LPPV acquisition process for RUSI, read it here.

He makes the point that the MoD is reluctant to adopt other models apart from the UOR and CADMID process;

The MoD appears to be generally reluctant to adopt alternative acquisition techniques (such as spiral development or incremental acquisition), which have the potential to mitigate the consequences of high technical risk and requirement uncertainty.

He concludes with a damning statement;

Smart  acquisition  was  intended  to  lead  to  improvements  in  new  equipment  delivery performance.  This has not  materialised,  and  the  practical application of CADMID by the MoD has been to create an ‘industry’ of supporting processes and management information, which is, arguably, largely a  product  of  insecurity  among  decision-makers  and  their  staff.  The result is to direct the focus of teams, perhaps inadvertently, towards feeding the process and not delivering the product (the equipment to be acquired).

An industry of process, insecurity among decision makers and ‘feeding the process’ are the exact opposite of what Textron achieved and Agile Development purports.

Agile may not be the answer, the Textron approach might not work for the MoD but would it be beyond the wit of man to try a few alternatives like them?

Share on facebook
Share on twitter
Share on linkedin
Share on pinterest

44 Responses

  1. It’s being used successfully. Gripen development has used it in both the software and hardware phases for example. A certain sensor manufacturer and certain small turbine manufacturer also use it…

    It’s a process that relies on everyone knowing and buying into the process in order to work, so similar to TPS in that respect. It’s also difficult to bring in new resources or partners who aren’t used to it. Typically you see projects adding resources slowly, as low as a handful at a time spread between existing teams. You’ll also see traditional PM’s engaged to manage external suppliers and partners, working closely with Scrum masters (or equivalent) to cross the bridge.

    Defining and creating the tests, software and physical, up front is key and then you develop against those. Budgets are less controlled however as development is more open ended. It tends to scare higher ups especially when large budgets are involved, hence one need why everyone needs to buy into it.

  2. Re: Foxhound – “It was bought into service very quickly but no corners were cut.”

    Not entirely true. Quite a few requirements were brushed away with the UOR stick.

  3. Textron has demonstrated what civilian industries do as a matter of course… airlines will decide what they want, seek out the type (and financial package) that best suits, talk to the manufacturer (who will invariably offer multiple options anyway) to get various changes they require, then contract for a set amount of units, at a set delivery rate…. The first few will be used to ‘bed in’, and any changes required passed back to the manufacturer. All of those factors may change according to commercial and market forces, and so the possibility is built into contracts and programmmes….Simples.

    …Something that might well focus your thinking….Both Airbus and Boeing have designed, developed, tested and introduced into service (with various degrees of success) new and innovative aircraft, In the same time that the MOD have been arsing about with FRES….

    …You can’t tell me that a AFV is more complex than a very large transport aircraft….

  4. Entirely my approach with my designs. Cooperation is a fundamental necessity if rapid progress to the Users’ ideal solution is the goal; the current over-specified us vs. them approach encourages both sides to constantly search out weaknesses in the opposition that can be exploited as contractual leverage (or ultimately excuses why it all went to rats).

    Light touch authority, hands-on involvement, eagerness and enthusiasm channelled not flattened under a mountain of specs and procedures. Once all the product definition and initial User trialling has been done all the rigour of CM must return, but treating first cut concepts as if they are production ready with laborious change procedures and constant funding vs. capability arguments with the customer doesn’t allow agility.

    In my opinion.

  5. All of these development processes have been around for many years, and are being used in many industries, very successfully, as a matter of course.
    Even within the defence industry- If you look at the development history of the Spitfire, Hurricane, Lancaster Mosquito and Mustang (remember, originally designed at the request of the British Purchasing Commission). All were the result of ‘agile’ development.
    Postwar, you could argue the Canberra and Hunter were of the same ilk…. So how the hell did we get to the current situation of arsing about and indecisive decision-makers. I doubt we can blame industry entirely….

  6. TD, I am sorry but your approach is almost laughable. I can see no way that a company like Textron can provide the valuable directorships and consultant positions that we desperately need to attract the “best” people to the MOD and services. :-)

    There are a number of programs although not in the UK that seem to fit well to this model. Harvest Hawk and the Intrepid Tiger II pod both fit in well. it’s a no brainier that the quicker a project goes the cheaper it will be. It’s the messing around with power points and consultants that make everything expensive. Large companies like LM and BAE staffed by an never ending stream of mediocre managers and engineers with no skin in the game are also likely the problem as well. These companies don’t spend a dime of their own money on development and are in effect little more than over paid government departments maintained by the desire of current government staff to get a cushy job when they retire.

    Another prime example of this approach is space X. while they have convinced NASA they still seem to have some major issues convincing the USAF that the monopoly of Launch alliance is a bad thing.

    General Atomics and its new avenger UAS would also be another good example. A even BAE managed to do an amazing amount with Taranis when you consider the same £400 million budget is what it’s costing just to integrate storm shadow with Typhoon. Obviously though BAE has skin in the game when it comes to Taranis that it jointly paid for.

  7. “Large companies like LM and BAE staffed by an never ending stream of mediocre managers and engineers with no skin in the game are also likely the problem as well. These companies don’t spend a dime of their own money on development and are in effect little more than over paid government departments maintained by the desire of current government staff to get a cushy job when they retire.”
    I think that’s a gross over-simplification, though there is undoubtedly some truth as well.
    All the large companies spend on R&D. BAE’s land domain in Europe has been focussed on Hagglunds for as long as there has been a BAE land domain. GD developed the Piranha V on their own coin, LM bought into the land market in the UK through R&D.
    As for the engineers and managers, there are good along with the bad. With a larger organisation you’re bound to see more of both, especially when dealing with the feast and famine in the defence sector.
    Still, I suspect that the MoD, through their own actions, end up paying for more powerpoint presentations and process feeding than they really need.

    I’d be interested to know where your good examples (General Atomics and Space X get their staff from.) I suspect it might be from the big companies.

  8. In my experience its not a case of engineers and managers being mediocre that makes big corporations stodgy or uninspiring, but the corporate mantra that everything must be done to a process. Big businesses create big processes in the belief that the processes force people to excel by preventing bad practice.

    The reality is more generally that the process becomes so precise and inflexible that lightly trained chimpanzees couldn’t go wrong – there is no way to move fast when it would be valuable, or to use initiative, or to engage enthusiasm. The days are filled with meetings involving a dozen or more departments discussing impacts and process compliance and minimally compliant solutions. There is no room for the will to live in such meetings. Indeed, many of the bright people that have been described mediocre just above are ex-services personnel who thought they could inject some realism enthusiasm and pragmatism into lack-lustre industry, only to find they too were terminally weighed down by corporate policy and enforced committee decision processes.

    Not that the industry has any choice in the matter; to comply with ISO or AQAP quality rules everything must have a written process, and MOD will only deal with organisations that pass their quality audit. On top of that to gain extra gold stars industry is ranked on CMMI process model league tables where absolute process is again the core of the assessment.

    And the same process focus applies within all sectors – MOD too. I have seen MOD personnel knowingly refuse to move forward on potentially life-preserving issues because the process did not allow them to act as necessary. Nothing is more important than Process.

  9. The old days of the Skunk Works under the leadership of Kelly Johnson and later his protégé Ben R Rich utilized this type of thinking to make amazing things happen , quickly and on budget. An example would be the first two prototypes of the F-117 developed under Ben Rich’s tenure. Once ( eventually) the USAF had been convinced of the fact practical ‘stealth’ was acheivable order the two prototypes. 14 months later they were flying utilizing proven tech and components from existing USAF aircraft to smooth the way as part of the design philosophy ( literally not reinventing the wheel by utilizing an existing aircrafts under carriage etc, F16’s fly by wire control system and cockpit layout etc ) Ben R Rich’s book Skunk Works is a brilliant read and slams the edifice of USAF/USN/Pentagon processes that weigh down project development and fruition.

  10. @ Mr Fred – in the case of Space X a lot of their staff come from other rocket companies. However they took junior guys on that were fed up of working in the traditional way of tinkering with 40 year old rockets and producing nothing but endless power point presentations and over inflated bills for government.

    space x has even been criticised by others for relying too much on actually building stuff instead of multi million dollar simulations that tell nothing.

  11. Space X have acheived certification to launch USAF payloads back in May. Elon Musk challenged publicly several times the USAF for slow rolling the process and took them to court over awarding ULA a block of launches which they couldn’t compete on as they weren’t certified. United Launch Alliance was the only bidder ;-)
    Space X along with the other independent launcher developers are casting off the old government owned and funded processes and slashing the time to get a launcher ready for presentation for certification. By just building and ground testing their ideas with a view to having it certified ‘one day’ means many tiers of management and bureaucracy are eliminated with always in the engineers mind what the end goal has to be, a certified launcher, but not letting the minuitea of compliance at every tiny step stifle innovation and progress to the end goal of a working commercially competitive launcher.

  12. it was quite shameful what the USAF was trying to do by awarding such a large contract just before space x was certified. even allowing the only two competitors in the market to form a united launch alliance in the first place.

    when we think the MOD is bad we only have to cast a gaze at the Pentagon to realise it could be even worse. Perhaps allowing our top brass to hang around theirs is half the problem :-)

  13. “The best minds of my generation are thinking about how to make people click ads.”

    – Elon Musk

  14. TD – great piece. One question (I’ve reread the article but can’t figure it out) – where is the quote on the Scorpion relative to the standard DoD process from?

  15. TOC – ref clicking ads – how sad that the height of intellect now is focused on the latest must-have sparkly trinket of social media. Mental chewing gum; the stuff people soak up and mindlessly chew – consumption out of habit that turns into an addiction. There will be riots in the street when the mobile networks are switched off, and a raft of zombie-like youth not knowing what to do or where to go because the App that used to decide for them doesn’t work any more.

  16. A software engineer friend of mine, said he liked to work for companies where if a new line of software worked, but only just, they kept a note of it, so if there was a problem in the future, they knew where to go back to. He hated working for firms that could not be bothered(because of a deadline) to do that, because if they got a fault, they did not have a clue where the problem was.

  17. Spent most of my working life deep in these kind of issues. Process is not the key, just pick one and stick with it. There’s dozens if not hundreds to pick from. The key is good, smart, industrious people in the right roles.

    Scorpion is a terrible example because it has no customer & therefore, no requirements to meet and has the only internal goal of being cheap. Any fool and any fool company with money to burn can go into a shed with no windows and build a working ship, tank or aircraft that in no way advances the start of the art. It’s building something that involves risk, stretch, leaps into the unknown, with an impatient customer with a constantly changing mind, that’s hard. Try it sometime and you’ll have as many gray hairs as me.

  18. Barbarossa said: “Even within the defence industry- If you look at the development history of the Spitfire, Hurricane, Lancaster Mosquito and Mustang (remember, originally designed at the request of the British Purchasing Commission). All were the result of ‘agile’ development.”

    There were 24 variants of Spitfire and Merlin engines went in all kinds of aircraft. That is just how things were done. Well, there was a war on. Fairly autonomous departments able to stamp out a few tens or hundreds of aircraft, then repeat that with a new variant to fix deficiencies and improve performance. And you keep doing that. Even Eurofighter has gone through that process with Tranche 1, 2 and 3 but the delay in getting even the Tranche 1 aircraft into service was ridiculous – and presumably mostly political.

    I think military equipment manufacturers and procurers have gone down something of a blind alley – that of only thoroughly new products being seen as progress. New seats. New weapons. New sensors. New materials. New construction methods. etc. There is nothing wrong with parts bin raiding.

    On a slightly different theme – I’m sure A400m could have been in the air a lot sooner and stood a better chance of export sales had the programme been more modest and aimed at performance upgrades coming through later. It could have been a more voluminous Hercules equivalent with off the shelf engines and nothing too cutting edge materials wise, with the big composite wing and more powerful engines as part of a planned performance upgrade. Germany and France would have got an uplift in capability with a Mk1 version and then a second uplift through Mk2 versions being produced. It didn’t need to be such a massive leap in capability over the competition in the first instance.

    Ron5 said: “It’s building something that involves risk, stretch, leaps into the unknown, with an impatient customer with a constantly changing mind, that’s hard. ”

    That sounds a lot like UK defence procurement which frequently turns up late, over budget and under-performing, if at all. Is there any particular reason why a new product must advance the state of the art?

  19. ADG – customer demands state of the art. In the UK this is I am sure because there are so few major programmes that the idea of ‘wasting the opportunity’ with a minor step forward is unconscionable – if there’s only going to be one new aircraft type/ship class/vehicle family per decade then the customer set will pile every possible technical advance into its requirement.

  20. There is definitely a theme that requires army vehicles to be revolutionary, which has led to the FV430 still being in service after six decades, the CVR(T) running into its fourth decade and a great deal of time and money being thrown away.

  21. mr.fred – just a note here; my designs are indeed somewhat revolutionary, however the technology used is most definitely current. As I see engineering it is rarely the design that causes headaches and long delays, it is immature cutting-edge technology that really throws up difficulties.

  22. Chris,
    Looking at past performance, I would view a revolutionary design as being very much a negative as it involves more risk. If you had a spiral development part to integrate the revolutionary aspects in stages, and a route back if it proved unsatisfactory, then that might be interesting.

  23. mr.fred – looks like we might need to agree to differ… Using known performance technology and component systems in unconventional configurations to my mind does little to the risk compared to using those same components in a different more conventional configuration. Indeed you might well inject greater risk in demanding an upgrade to a known transmission (for example) that required ceramic bearings and micro-crystalline sintered gearsets to get to the required torque transmission capability, in place of steel roller bearings and gears. As I said before, I believe new technology holds much greater risk than unusual design.

  24. Chris,

    I agree that the technology may pose a greater risk, but the risk associated with radically different designs may also be significant and not to be lightly thrown aside. If nothing else, going into the unknown will raise concerns with the customer and how he intends to use it. If you have nothing to show him that either your concept will work or that you can revert to something which is known to work then that’s some risk hanging over you.

  25. Interesting question about Agile methodologies.

    I think you have to put your tongue firmly in your cheek when you think about the reality of “agile”. As some have already said here it has been around for years, in fact I think you’ll find most of our churches and cathedrals were built using an agile methodology.

    The main thing that agile dispels is the compensation mentality in that it promotes the supplier working WITH the customer (and vice versa).

    It removes the “them” and “us”. It also promotes transparency of progress so allows the customer to actually see the effect of some of their less sensible decisions.

    So not agile for agile’s sake with scrums, sprints, burn-downs and backlogs. Better to simply promote the idea of teams working together for a common goal.

  26. Translations
    “Projects are built around motivated individuals, who should be trusted”
    Senior Management, you are not welcome at my meetings

    “Face-to-face conversation is the best form of communication (co-location)”
    Additionally, I dont hold meetings.

    When it works, its fantastic, I can (and have, and do) increase departmental output by 20-50% in 3-6 months.

    The problems occur when people who should only be interested in the outputs (or even worse, shouldnt even be interested in the outputs) start trying to get involved in the process.
    Its at that point I usually quit.

    You would not believe how often I get in to arguments with Finance Directors who have a deeply unhealthy belief that their experience from 1972 is somehow relevant.
    Paraphrasing but
    Me: “I’ve sat down with your credit controllers and we’ve come up with this report, takes 5 minutes to run in the morning, so far average daily cash collections are up 20%, its only been a week but thats pretty promising.”
    Moron: “My credit controllers wouldnt be interested in a report like that”
    Me: “No, its the information they asked for, they already use and love it”
    Moron: “You shouldnt have issued it without my permission, *I* tell my credit controllers what debt to chase each day”

    And to my knowledge he does, to this day, the FD of a fairly sizeable SME every couple of days generates a list of clients for his credit controllers to chase for payment, and wonders why his aged and bad debts are killing his business.

    I’m quite a fan of “process manuals”, as long as the person who wrote them actually *does* the process, process manuals written by the managers of people who actually do the process are generally gibberish (I was actually sent one where the manager didnt know a new piece of software had been bought so wrote a “new” process manually for the old software).
    Processess for designing new processess are pure fiction in my experience, and I can understand how they can shut organisations down.
    But A decent process manual can be knocked out in an hour with snipping tool and word.

    So, yeah, my main working problems are high ups who want to be involved with things that are really none of their business.

  27. If you were correct the RAF would still be flying Sopwith Camels. Defense products HAVE to raise the bar to meet or beat the bad guys who don’t stand still. You want Russia or China or North Korea or ISIS to be the first to implement new weapon technologies??

  28. The problem is that fundamentally, customers and suppliers have very different goals. ’twill always be so.

  29. TrT – my issue in one with the ‘big process’ business model. Guaranteed review meetings with every conceivable department represented, all with an equal say over the way tasks they don’t really understand should be done. Worse still the voices with greater clout (managers) automatically veto the voices of those that actually do the work. It looks really clever and intelligent when described in the process documentation, in reality its pretty dumb, with outcomes like partitioning of budgets purely on grounds of what makes the finance department’s job easier to compile accounts, rather than on project specific needs, because the finance director attended the review meeting and his voice outranked everyone else’s.

    I have seen heavy process corporations at work – why bother to recruit the brightest most experienced people if their work will be entirely and in minute detail controlled by unchangeable process? If the process is so proscriptive – they often are – that every task has a form, every form has detailed instructions on what to put in each box and who to pass the form to then why not recruit a bunch of eager school-leavers instead? As long as they are literate and follow the detailed instructions they can’t go wrong.

  30. The point I was trying to make is that alternative models exist and there are numerous examples but if you refuse to try them, you will never know.

    That the MoD has CADMID and UOR, with nothing inbetween and no willingness to experiment, is a shame.

    Am not saying we should develop Successor using an alternative method but a lower risk project might be a good test in order to see if it works, or not

  31. It also depends on the size of the programme – smaller programmes can be more agile than huge ones, partly because the team needed to perform the work is smaller, partly because the cash risk if things go off the rails a bit is more affordable. The really big programmes will always attract extreme scrutiny across the board and to great depth – light touch management wouldn’t be suitable.

  32. Chris, like Nimrod, Typhoon, Astute, T45, CVF and FRES?

    Money can be professionally wasted even with large programs and supposedly better development processes.

  33. Simon – don’t get me wrong – I am a strong advocate for cooperative working, where all parties muck in and do real work as a team. To my eyes the IPTs in MOD’s procurement organisation are neither integrated nor teams; they remain resolutely authoritarian customers bent upon management by audit and criticism, reinforcing the us & them mindset rather than smoothing it away. A team only exists when all involved want the same outcome and all are putting in as productive an effort as is possible to achieve the goal. Watching from afar and providing input along the lines of “You, Boy, you are not working hard enough! And you over there – that’s not what we wanted! Do it again!” doesn’t cut it.

    But. When it comes to hundreds, possibly thousands, of contributing workers across dozens of companies on projects that will, even with the best intentions, take decades to complete, there needs to be a discipline; a way of making all those disparate groups of workers work as a coherent whole, in synch with their piers and aware of all the changes that affect their efforts. As much as it hurts to say it, processes have to be put in place and followed. I am sure the right approach is to use the minimum of processes necessary to keep all on the same track, with the minimum volume of meetings (volume measured in man-hours).

    A study was done several years ago I think by the Digital Equipment Corp, when PDP11 and VAX were the bees-knees of computing. They looked at parallelism in processing using the new object oriented coding methods. What they found was a diminishing return when adding additional parallel processors – adding a second to the original increased throughput by 60% over the first, the other 40% processing effort was in synchronising data between the processors. Adding a third put total throughput up 80% over the original single processor, adding a fourth had total throughput 60% greater than the single machine. It had got to the point where adding extra parallel effort was detrimental to the volume of work throughput just for the effort of keeping all the working elements updated and synchronised. I might not have remembered the numbers correctly, but the study did show the effect described. I believe it was this study that triggered development of the transputer; a fine bit of British engineering, designed from the outset to communicate in parallel to many other similar transputers to form a realtime network of processors munching common data (as I understood it). Ultimately overtaken by Intel’s 8086 descendants that most of us still use today that were the result of a vastly greater R&D budget and hence a much faster growth in capacity and capability. But the original study still has relevance in business – there comes a point where adding staff is counter-productive as the effort required to keep the team coherent burns more man-hours than the extra staff added into the project.

  34. Ahh…VAX….first task….get pressure up in the boilers and then open the steam valves….then turn it on and hope for the best :)

  35. Chris,

    I presume you’re alluding to the “law of diminishing returns”.

    I understand that. In fact if you think about it a large organisation that requires communication down and back up the hierarchy cannot actually be agile. The only way to speed up the communication cycle is to not escalate and make decisions at lower levels.

    This is essentially the agile methodology in a nutshell: a fifteen-minute stand-up meeting with the team and a full evaluation after the sprint (every couple of weeks) followed by a re-prioritisation of the backlog.

    Large organisation that need to keep their finger on the pulse (positive phrase) or like to interfere (the reality) simply can’t fit the meetings in necessary to communicate internally.

    Monday AM: MD meets with directors
    Monday PM: Directors meet with senior management
    Tuesday AM: Senior management meet with line managers
    Tuesday PM: Line managers meet with team leaders
    Wednesday AM: Team leaders meet with the team
    Wednesday PM: Work is done.
    Thursday AM: Team reconvenes to discuss problems
    Thursday PM: Team leader communicates back to line manager
    Friday AM: Line manager meets with senior management
    Friday PM: Senior management meet with directors
    Saturday AM: Directors meet with MD

    Okay, it doesn’t really work like this but it’s fun to think about ;-)

  36. The DEC study (if it was indeed done by them) didn’t just determine diminishing returns, at a certain mass of supposedly parallel elements adding more ‘help’ slowed the total workflow down – can you have negative returns? Subtractive returns?

    I recall there was a US business guru called Tom Peters. I read his book (one of them). He advocated Management By Wandering About. MBWA. His observation was that businesses where the management went to each of their staff for a coffee-machine natter to understand progress and issues seemed to work in a much more fluid manner. The workers (for want of a better term) stayed on the job, they weren’t taken out of their comfort zone to explain themselves in a massed managers’ meeting, they were left to do what they were employed to do. The management on the other hand tended to get fairly clear unambiguous status and issue lists uncoloured by large forum discussions. It has to be said though, that the shining examples Peters used to showcase MBWA all later fell off the rails, almost certainly when they increased headcount beyond the mass MBWA could realistically control.

  37. @Alex

    Excellent! Parts now ordered. Going to be a busy August in the TOC Shed of Wonder… :)

    EDIT: Yeah, we can improve on this. UV imagers also available online from the supplier and I already have a garage-built SAR to cue. Wife says no to a larger quadrotor purchase for airborne surveillance though…

    EDIT 2: Filament prices have shot up. When did that happen? Thought oil price was down on last year!

  38. Ron5 said: “If you were correct the RAF would still be flying Sopwith Camels. Defense products HAVE to raise the bar to meet or beat the bad guys who don’t stand still. You want Russia or China or North Korea or ISIS to be the first to implement new weapon technologies??”

    I think too often the MoD insists on revolution when evolution would be good enough. To use the Sopwith Camel as an example – current big ticket projects seem to me to be like if the RAF had stuck with Camels until jet powered aircraft were in production, for the arbitrary reason of turbines being a revolution in performance and design whereas aircraft before were just like Camels only better. For a time everyone else would have sleek monoplane designs while the RAF kept its Camels and the RAF would excuse this situation by saying ‘Jets are just around the corner’.

    Peer quality equipment in sufficient quantities is not a revolutionary approach to take but the MoD seem too often unwilling to do it.

  39. Something like the Air Tractor AT-802U Archangel, Turbo-Prop with Stuka (Sturzkampfflugzeug) Siren on it. As a Night-Attack Low/Slow Attack STOL Aircraft. Or something like, the Stavatti Aerospace SM-27S Machete, Turbo-Prop Pusher Attack Aircraft, or uprated SM-27T Machete II, Turbo-Fan Attack Aircraft…

  40. Trainers always look so strangely proportioned given how large the two man cockpit looks compared to a much smaller aircraft.

    I still struggle to figure out where an explicitly light fighter fits. If a drone can do it a drone is probably cheaper. If a drone can’t do it then can a light aircraft like this? Maybe, just not sure that gap is big enough to sustain a program.

    Could be interesting certainly, wonder if the USAF will buy into Boeings manufacturing cost promises. They clearly didn’t on the B-21.

  41. Re: Light Fighter

    In my opinion there is space for a light fighter, but really only to make up the numbers. So we could have our twin engined Typhoons and another single engined jet that preferably uses the same EJ200.

    If we avoid this multi-role falacy and concentrate on air defence (agile and AAM only) or strike for the numeric advantage of bombs on target then I think there is mileage in either.

    Using this as a trainer is also extremely sensible especially since a lot can be done with software to simulate combat systems nowadays. If one looks to the future a little further we can see that with the exception of the basic-six just about everything will be in a smart helmet. So pilots should be able to train in combat whilst driving down the M1 :-)

Comments are closed.