Xp Challenge Pace Makers

Formerly ExtremeProgrammingChallengeThree

From ExtremeProgrammingChallenge. Let's take this thing called ExtremeProgramming and play with it... push its limits. How would we do XP?

Scenario 3:

You've been hired to consult at a company that makes pacemakers and other small medical devices. Embedded software. The users will never know that they are using it. The company wavers between using assembly language, C, and Ada for their development. The smaller instruments have a very tight memory requirements. Performance is an issue. The larger out-of-body devices have more leeway. Regardless, safety is absolutely critical. Designs are deliberated and picked apart diagrammatically before a drop of code is written. The FDA may come in and audit at any time, and it is important that a high degree of ceremony is in place. A couple of young ruffians on the staff have heard about XP, and they wonder whether it can offer them anything.

Since documents are important, adapt XP to them. (When programs are more important, you use traditional XP). For instance, use PairProgramming while drawing your diagrams. Specifications and programs share common characteristics. For example, names are important, modularity is important even for specs. I think XP practices will apply for them as well, especially if you have tools, or are using a functional or logic language to get executable specifications. Then specifications are "just programs". Alternatively, try and get them to write "drops" of code and refactor them to get a feel for the design. -- AamodSane

The XP values are Simplicity, Communication, Testing, and Aggressiveness. These guys are already focused on communication, although I question how much analysis and examination of UML or similar diagrams can ensure that the programs are actually correct.

RelentlessTesting is critical to any such process, and I'd prefer that the code be tested, not just the diagram, if it's my heart you're pacing. I'd definitely want a BlackTeam orientation to testing, such as you get with XP's AcceptanceTests.

Simple code is easier to understand, get right, and verify. These products are not a place for complexity. Start simple and refactor the code for more simplicity until every method is written once and only once, so that you can be certain that each is correct.

Pair programming amounts to continuous code review. As such, it will increase the reliability of any system, whether used on its own or in conjunction with other forms of review and verification. -- RonJeffries

In this scenario the alleged matters are size, performance and testing. I can't imagine any of these three pose a problem to XP. With auto-regression-testing, performance monitoring tools, and RefactorMercilessly, you will get size and performance within limits as well as anything imaginable. With pair programming, unit tests and functional tests you get most of the rest of your tests. The only open question to me is, do you also want program proofs of correctness and review boards? Could I imagine adding those to XP? Well, I could, but I'm not the XP inventor. They themselves have to answer that to their satisfaction. -- AlistairCockburn

Yes. In this scenario, the real issue is safety and its partner: fear. You have to be safe, but you can not be so scared that you prevent rational improvements to process. This scenario is conservatism incarnate. And with good reason. -- MichaelFeathers

I swiped the structure of the CommitmentSchedule from a pacemaker project done by JonHopkins?. I also swiped the idea of creating a running system in the first iteration from him. As I remember the story, the first requirement they implemented was the dynamic restart when everything went to hell. They made sure that everything else they implemented worked within that context, and they had many many months of testing on the feature most important for continuous operation. -- KentBeck

I'll throw in the perspective of someone with 15 years of experience on pacemaker projects.

We spend the most time, by far, on requirements specification. Almost the entire organization relies on the Product Specification to be the last word on how the thing is supposed to work. The product must be described in the finest detail imaginable, so you can imagine how much time is spent discussing, arguing, and updating the contents of this document.

Once the team achieves mutual understanding of the product they're building, the rest is, relatively speaking, a piece of cake. The reason it gets easier is because you have something to test your design and code against.

Could we use ExtremeProgramming to improve our productivity? Sure! The only problem is that ExtremeProgramming does not address the aspect of the project where we spend the most time. Coming up with a method for "Extreme Requirements Definition" would involve developing rules for controlling group dynamics and corporate culture. Good luck!

To answer Alistair's questions about proofs of correctness and review boards -

I've never seen a proof of correctness, and our products work just fine, thank you.

As for review boards, they are important for requirements definition and clarification. I don't see why PairProgramming couldn't replace design and code walkthroughs. -- SusanJohnson

I made up the example of a pacemaker project without having any idea of the amount of software involved, and I still have no idea. Can anyone mention without giving away the farm? Also, I wonder whether XP requirements definition could be done by actively working out a simulation in code and testing it all along the way during specification. It may make no sense at all. I don't know how feature-laden pacemakers are.. and whether working code could focus specification effort by providing feedback. -- MichaelFeathers

The latest pacemakers have 16K - 64K of ROM. The features are increasing all the time. The external instrument used by a clinician to talk to the pacemaker has a PC architecture. Its software is up to approx. 3 million lines of code, for those who use such metrics.

Certainly simulation and prototyping are used to understand the requirements of both the pacemaker and instrument (called a programmer). But there's always the usual discussion of "in scenario X, should it behave this way or this way?" So you try to find experts to answer the question, and sometimes they don't agree. Sometimes they'll change their mind 3 months later.

I'm sure there are other application domains where the requirements specification is critical, and there isn't necessarily an obvious answer to all the important questions. -- SusanJohnson

If you use XP to build pacemaker software, I'm going to another vendor.

There is plenty of evidence out there that shows that XP can be used to create software with fewer defects than the majority of office and enterprise software out there. I haven't seen a scrap of evidence that shows that XP is safe to use when your life is on the line. If you're making pacemakers, I want your programmers to write code like the NASA JPL does - that anal-retentive, formal-proof stuff. I'll trust my bank account to unit tests, but not my heart. XP is simply not intended for this level of quality. That's no knock against XP, HorsesForCourses and all that.

--RobMandeville

One highly relevant paper is here: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.93.3141&rep=rep1&type=pdf

"Static Verification and Extreme Programming", Peter Amey, Roderick Chapman, Praxis Critical Systems

Abstract: At first glance, the worlds of high-integrity software engineering and Extreme Programming (XP) seem to have little in common. Somewhat surprisingly, we have found the reverse to be the case—indeed it seems that many practices advocated by the XP community are familiar to us from many years’ of experience in building safety - and security-critical systems. This paper discusses our experiences in applying some XP practices in critical projects. Secondly, we discuss how static verification can augment XP, particularly in the Pairwise Programming and Refactoring practices.

--DavidAllsopp