Process Misfit

When a process chooses the bad solutions to tackle the problem at hand.

See MichaelJackson's SoftwareRequirementsAndSpecification?, and the quote in NoProcess page.

For example: a particular problem might be in dire need of BigDesignUpFront, but the process used mandates no BigDesignUpFront, and instead imposes DoSimpleThings, RefactorMercilessly, ListenToTheCode and the likes.

For example?

Another very common example: if you're going to use a relational database, you gonna have to do database design.

XP still has to figure out how to do RefactoringWithRelationalDatabases.

While if you happen to be in the possession of the RUP product, and go to Artifacts -> ... -> Data Model, you'll see one of the worse divagations on the subject. Largely it is the same as the publicly available document cited here in ObjectRelationalPsychologicalMismatch. Also "Core Workflows" -> ... "Database Design" contains equally bad advices, misinformatrion, and in general if you want to do database design at all, ignore everything RUP has to say, and study the real things written on the subject.

Yet another example: concurrent programming.

UnitTests for concurrent programming are almost useless. All right they might discover some trivial bugs. ListenToTheCode and RefactorMercilessly is also inapplicable; you can listen to the code all the day, but it won't tell you anything about concurrent issues. It is almost imposiible to write a test that will simulate particular concurrent conditions under which the system will fail.

This myth is put to rest in ExtremeProgrammingChallengeFourteen. It qualifies as "somewhat hard" rather than "almost impossible".

From what I understood it happened there, the UnitTest was written only after the problem was made known, and it was only a very small example. In general problems in concurrent systems are a matter of implementation, and writing sound implementation code for concurrent systems is a matter of serious design upfront.

I'd qualify this as MovingGoalPosts. The above states that it's "almost impossible" to write a test that exposes a particular failure condition for a concurrent system. Challenge Fourteen is about exposing in a test a particular failure condition of the sort that could happen in a real system. The challenge was solved in a few hours. The above statement is therefore false.

We should generally be wary of statements that something is "impossible" or "almost impossible", unless it's a matter of logical impossibility. Whether it's desirable or useful to apply TestFirstDesign to code dealing with concurrency constructs is another matter, but the "impossible" argument is unconvincing.

The fact is that there are already other methods put in place to write concurrent systems, which are better fit for this particular problem than XP will ever be. This page is about fitting the process to the problem. A process that is designed specifically to deal with concurrent and real time issues, and desiugned by domain experts, will always be better than one size fits all solutions.

I still maintain that is is almost impossible to write upfront test that will simulate failure conditions. Logically you can't do so unless you alter the code, to synchronize on a particular order of execution, because you usually cannot get the runtime scheduler to do it in a particular way. This contradicts the "test what you fly, and fly what you test" principle. Even if you get across the barrier of how to determine a predefined execution during the tests, there is the combinatorial explosion of such possible orders. The two clients, two methods, one object problem in Challenge Fourteen is just a toy comparing to the kind of things that can happen is real concurrent systems.

You might want to take into account, formal specification and formal proof methods, which I think in other circumstances would be easily qualified as BigDesignUpFront, but anyway, I have yet to see convincing evidence that customer stories, CRCs, TestFirstDesign, RefactorMercilessly and everything else work efficiently in dealing with writing concurrent systems. They were not conceived to do that in the first place.

Do you really think that the great extremos discovered the philosopher's stone of computer programming, that should work everywhere ?

Would someone who knows Xp really well please tell us if Xp precludes the use of CSP for modelling communicating concurrent processes?

It equally applies to database transaction code, be it stored procedure or client/server from a host language. Don't expect RUP to come up with any useful solution either.

To make sure your code works, a little bit of reasoning about the code and even formal proofs if necessary are almost the only way to go in the majority of cases.