Re:Origins of XP (Score 1)

It is quite interesting that you say this since a frequent criticism of XP is that it only works well for teams of good developers, who would presumably do pretty well using most methodologies. I can't see why managers would be so keen on XP either, since most managers would probably prefer methodologies which promise repeatable results.

XP gives you deliverable for incremental steps. This kind of accountability (resulting in predictibility) is exactly what a manager wants.

Oh, you call tests and refactoring overhead! Um, have you ever noticed that when a developer adds a feature to some software, or fixes a bug, there is a significant chance that he breaks the software. Therefore, if there are no tests in place he will have to test manually, which is a lot slower.

They are overhead with respect to the actual code which is shipped and run. The tests are not part of the deliverable. I'm not against tests themselves. But bad code will require more testing until you find yourself comfortable with the code. Redesign is overhead as well. If you do it the TDD (test driven development - see new topic on /.) way, you will find yourself constantly doing refactoring. TDD consists of three steps: write a test, write hacky code to make the test pass, refactor and iterate over it. A lot of emphasis is put on writing tests and refactoring, which means that you will spend less time on writing actual code. If you're a bad developer, this is a great way to get concrete working results, but he/she will progress very slowly.

Riiight, and if the system is actually useful the people who use it will want you to extend it. Or maybe they only use certain parts of it and want a more lightweight configuration with just some additional features. Or, maybe the system needs to be integrated with webservice X and legacy system Y. The point is that the designer, no matter how good he/she is, could possibly anticipate which one of these scenarios actually happened. Therefore either the design takes all of them into account, which means the system is incredibly bloated (not necessarily in execution but design-wise), or alternatively you will have to do redesign and/or refactoring. Both of these are a lot nicer to do if you have unit tests in place. That is why XP advocates unit tests and refactoring together.

Well, good design is trying to do that. There are always requirements which you cannot anticipate. The challenge is to design software such that the cases of such requirements are minimized.

XP is not inherently anti-design. XP is geared towards application areas where requirements change frequently. Up-front design is therefore replaced with continuous redesign using refactoring. It should also be noted that other agile methodologies are not quite as radical as XP on this point, and they usually recommend a short up-front design period at the beginning of the project and/or iteration.

I agree with you that XP is meant for applications. But as soon as an application becomes bigger, what happens? It will be broken up into modules, libraries, layers, .. things which will justify an API. I'm not for upfront design of a whole system. It's just that I prefer designing ahead a little bit for each bit of feature which is added. In some way it's TDD in reverse order.

Maybe Gamma et al. and Design Patterns could be a start.

If good design was simply a matter of applying the right design pattern, that would be nice! Thinking in patterns helps, but I find only few concrete patterns in the book really important: Decorator/Proxy and Factory. There's one danger in using patterns as well: you end up reimplementing the same pattern over and over, resulting in redundancy and possible bugs. I like the idea of LOKI (Modern C++ Design by Alexandrescu) which uses C++ templates for implemnting patterns. All the specifics of a pattern are provided by policies, which the developer can write, but the pattern it self is written in code exactly once. That's really the level of reuse I'm striving for. Each concept ideally should be implemented only one time. Otherwise a system will be bloated with redundancy, which is bad design, which leads again to a lot of refactoring. Redundancy also leads to more bugs, since different code paths are taken (and might be untested) for essentially the same thing (more testing). I hope you understand now why I call refactoring and testing 'overhead'. They are mostly inevitable, but that doesn't mean that we have to spend most of time doing it. Writing code is really what we ultimately want.