The real problem seem to me that XP is going out of its way to downplay foresight and planning. In a world in which applications frequently, if not invariably, are extended to do more that originally intended, solving for the minimum is frequently not a good choice. - Glenn Martin Fair enough. The real problem with that line of thought however is it reasons with the benefit of hindsight. There's an example given about spiralling logging requirements. But how would you know that beforehand? You might think to yourself in reflection that was obvious, but if it was so obvious why did you have let events occur to see that it was obvious? [Yes, it's circular reasoning, but that's the point] Perhaps the answer is that it wasn't obvious, with any amount of foresight, just with hindsight. In the same way, solutions to NP hard to problems tend to be only "obvious" in hindsight. Before that they remain NP hard. The suggested answer to the mentioned logging problem is to log asynchronously (which is a very good one, let's be clear on that). That's fine, but by the time you do design your way out for all functional and non-functional aspects of even a medium sized system, chances are you'll have bled the customer dry thanks to futureproofing and still they won't have what they need today. Assuming of course that your guesses worked out to be right. It's just not as simple as splitting matters in early design or delayed design. If it were, we'd know what to do by now :) It's hard to see how you design for the future, when you don't what that future it is, or even which future will be. Even if you did design the ideal system, it's only ideal insofar as the requirements don't change any further into the future. There are only so many corners you can see around, unless you're building the same thing over and over (perhaps you are). So I don't see that you can rely on foresight, even when you're lucky :) I think you can to some degree, architect very broad frameworks or platforms that many solutions can run on (I'm thinking of things like .NET, J2EE, the Web, JXTA or even operating systems) , but I don't think it's like that when it comes to requirements heavy or customer driven systems. There's any number of failed over-engineered, over-designed projects. They fail not only because they lacked the needed focus on requirements (what does system need to do?) but also because they encourage a situation where the project schedule has nothing to do with the amount of work involved - and there's enough of that going around the industry already without adding to it by overegging things. Designing software is not as simple as simply designing for the future you believe will be the case. That's just gambling on the customer's money. As such, it's not one iota better than the cowboy code and fix approach. What we want is risk management not gambling. Doing any design above and beyond requirements needs to be assessed against the risk of project and schedule failure. Not doing any significant upfront design also needs to be assessed. Now, there is one problem I (and others) have with the XP approach and that's what happens when you get published interfaces wrong the first time. They're in the wild, and you don't own all the callers (assuming you even know them), so you don't know what you;re breaking if you change. Martin Fowler calls this space published versus public. The answer in many cases seems to be not to rely on APIs for the interface. Thankfully there are options to consider for published interfaces other than API, such as internet protocols, REST and XML documents. By the way, there's a whole school of thought within XP of programming towards patterns (known solutions), that has not been mentioned or critiqued here. My own experience is that change is cheap when you have well factored code and a solid test suite to rely on. It doesn't really matter then when the change comes, just that you have tests and clean code before it comes. I should qualify cheap here - by cheap I mean affordable, timely with low risk of impact. There are many many systems out there that people are terrified to change. But again, there's nothing mentioned about the value of having taken out insurance through test coverage. So my admittedly narrow reading of Glenn's entry is that he has a narrow reading of what XP is offering. He has a good point if you take XP as dogma or perhaps have unwarranted expectations about what a software process gives you....
Previous Topic
