I have no idea where I'm going with this, but: Does anyone think that maybe the principles of ExtremeProgramming (or at least some of them) can be applied to other engineering disciplines? Say, electronic design? Obtain UserStories to describe how a product should work, break them down into EngineeringTask''''''s, test SpikeSolution''''''s, maybe even express your design as CRC (Component-Responsibility-Connection??) cards, etc.? Do concepts like RefactorMercilessly, OnceAndOnlyOnce, etc., apply to endeavors outside of software development? Feel free to poke holes in this, or trash it altogether. -- MikeSmith

I think the application is limited. ExtremeProgramming assumes/arranges that there are no really costly early investments. This just often isn't true in other fields - if any physical assets are needed that can't be re-used as the solution changes, you've wasted the investment, and since the investigations needed to decide what the assets need to be can be time- and money-consuming, you're more or less forced to do design up front.

I can't see ExtremeSkyscrapers, personally ('yes, I know we thought 10 stories was enough, but now we need 25') -- PaulHudson

I would guess you can apply XP principles to anything that like software is mostly design, not construction. -- MartijnMeijering

''True, of course. ExtremeDamBuilding or ExtremeHighwayConstruction just isn't going to work. But ExtremeHomeApplianceDesign, or ExtremeAudioEquipmentDesign, it seems to me, might have some possibilities. As you say, some disciplines have a high ratio of construction cost to design cost, and XP principles are obviously right out.'' -- MikeSmith

The manufacturing industries have been struggling with this for a long time. The big money doesn't go into designing things, it goes into the factories that make the things. But you want to build the factory before the design is done so you have to start with what you know you're going to need for sure, then refine it as you go along. Typically, you start out with an overly flexible basic design which gets specialized for a specific task.

''Most of my experience with design in electronics has been extreme in nature - pairs and all. This is because most of the design was done using various CAD tools with spike solutions built as throwaway prototypes. Of course, we built the test infrastructure first as well :-). -- ChanningWalton''

The more I think about it, the more areas I think of where (at least some of) the fundamental concepts can be applied. For example, ExtremeHighwayConstruction makes me think of the best way to figure out where to build sidewalks on a university campus: wait a while and let people walk over the grass where they want, then put sidewalks where the traffic was heaviest. Or even designing digital circuits (which I do). Many times the designs get stalled and stretched out as we try to dot the last i and cross the last t.  

Were we to approach it more ''extremely'', we would pay less attention to perfectionism and just build some core stuff, maybe prototype it, build more, pilot run the thing, maybe ship a few, realize where we'd really messed up and go back to improve it, and basically get to the point we want to be at much faster than if we'd followed "traditional" approaches.  

In essence, I'd have to say I ''am'' applying the principles to other forms of engineering, and even to process development itself (and documentation). After all, why should such elegant principles have a narrow field of application? -- PeterHansen

''One of the main reasons I used an approach similar to XP for building microwave/optoelectronic circuits was because we had a range of expertise and experience in the lab (it was a university research lab), and much was new (research). When I came across XP, it did not feel so different to how I used to work in electronics, I think a lot of engineers from other disciplines would also find it fairly natural. -- ChanningWalton''
----
CategoryEngineering