Infrastructure In Xp

When writing software, we use a lot of infrastructure: We use a computer that runs an operating system. We use an IDE. Maybe we use a RefactoringBrowser. Our IDE comes with a couple of class libraries, and we might even buy some others.

On the other hand, XP discourages extensive infrastructure. Simplicity rules.

Surely, nobody will insist on writing a new operating system for writing an accounting software, but some people (in the XP community at least) will object to buying SanFrancisco for the same project. But where is the limit? What is necessary or appropriate, and what is not?

I'll try do define a boundary condition here. Whatever our solution may look like, it must prevent our project from statements like:

: "Hey, and we will by that Blah-EJB Server first and that XYZ Database and use that Blubs-mapping tool in any case. Then our persistency team will develop data access services that will be available "just in time" before integration." --DierkKoenig

Actually for some projects everything up to "Then our persistency team..." might still be XP. Simplicity rules but there are some projects where these might be prerequisites due to NonFunctionalRequirements. --KyleBrown

I agree. SimplicityRules as well as ConcreteExperiments. Here is another condition. I don't want to hear:

: "We will meet the NonFunctionalRequirements of scalability and performance by using the Net-Stupid-Application-Content-Management-Suite-Server-Pages-Component-Model." --DierkKoenig

added clarification: that does not mean to always and blindly prefer make over buy.

Why not? If you see from the NonFunctionalRequirements (or user stories), that you will need to support certain characteristics, for example very high throughput, are you going to develop the required functionality *always* on your own? If you need a web server, are you going to write it yourself? If you need encryption, are you going to write your own SSL-Library (for example)? If not, when are you going to do the decisions and selections in an XP project? It might be necessary to use a component model to achieve certain characteristics, shouldn't you decide on that as early as possible because it influences the structure of the system? --PeterGassmann

Ok, good point. I have to forget my bad experiences with PrematureCommitmentToInfrastructure? to create a statement that you may agree to. I think that this is an excellent exercise for me. Thanks for your patience and please go on to challenge me.

: "Any infrastructure has to prove its promised NonFunctionalRequirements by ConcreteExperiments until we commit to it. It must be proven that the infrastructure is not doing more harm than good. It must be proven that we do not meet these requirements without that infrastructure. In case of commitment we prefer a way that does not limit our options to withdraw the commitment." --DierkKoenig

Agreed. Now the hard bit is: when is the right moment to do the ConcreteExperiments? Do we want them as early as possible? Probably yes. The only problem is: do we have the information we need that early in the project, e.g. are we (and the customer) sure about what is really needed? And here is my feeling that XP does not give enough guidance to ask the important questions, to find out about what is needed, particularly the non-functional requirements. Because the typical customer will not articulate the non-functional requirements just like that. We have to ask. --PeterGassmann

See ElicitingRequirements.

One step forward may be the rule: "Whatever you choose, DontLimitYourOptions".

But DontLimitYourOptions seems to advocate PrematureAbstraction (which I added on that page just now). And PrematureAbstraction is certainly anti-XP: You are adding complexity based on the assumption that you might want to switch to a different infrastructure in the future. --hh

At the end it is probably all about risks. Deciding to use a particular technology / tool / api ... has an associated risk of wrong choice. There are other risks like limiting your options, etc. But not deciding has also associated risks. Building something on your own has risks versus buying, which has yet another risks associated. So, to be successful in a project (probably with any methodology), one has to manage and track risks. Therefore, what you need from a methodology is guidance in identifying and dealing with risks. XP does a great job in certain areas, but I don't see a lot of guidance in dealing with the risks associated with the non-functional requirements (like scalability, security, availability etc.). --PeterGassmann

Perhaps one of the reasons is that it's not easy to test scalability, security, availability, etc. --hh

Probably right. Let's put a page together on HowToTestNonFunctionalRequirements. -- Peter