Semergence

Better Living Through Software

"RDF is often a whipping-boy, but a red-herring in this discussion."

Good discussion of RDF and SemWeb, explaining it and the issues.

Wired 11.09: The New X-Men

The Mountain Dew-fueled all-nighter is history. Today’s supercoders work 40 hours a week. And two to a computer. It’s called extreme programming - and it’s revolutionizing the software world.

Object Mentor - xpepisode.htm

In order to demonstrate XP (eXtreme Programming) practices, Bob Koss (RSK) and Bob Martin (RCM) will pair program a simple application while you watch like a fly on the wall. We will use test first design and a lot of refactoring to create our application. What follows is a faithful re-enactment of a programming episode that the two Bob’s actually did.

XProgramming.com - an Extreme Programming Resource

XProgramming.com is a resource for information about Extreme Programming (XP), the exciting new streamlined software development process originally described by Kent Beck. XProgramming.com is offered as a community resource for those interested in XP and related topics.

Specifically, it shows how unit tests and simple design work together while programming. Observe how the coding process occurs in small steps, just enough implementation to make each test run. There’s a rhythm to it, like a pendulum of a clock: test a little, code a little, test a little, code a little.

I’m a big fan of Test Driven Development (TDD). My favorite aspect is that it allows me to write the least amount of code possible. I spent time making tests pass, instead of coming up with the coolest way to do it.

Emergent Design vs. Early Prototyping - Software Reality

However, early prototyping (used correctly) provides many of the benefits of an agile approach (for example early feedback), whilst retaining the more rigorous benefits gained from designing a system before coding it up.

This article seems to forget all about XP’s Spike Solution phase. In this phase, if the solution to a problem is unknown, it’s OK to do a Spike Solution. This is a quick test of a small slice of an application to prove, or figure out, what and where the pieces of an application might be. For instance, if there is a new persistence layer that might be nice to use, test it out in a Spike Solution.

From practical experience, every prototype solution always gets deployed to production. Why not, from the start, treat all code as production?

Software Reality - EJB’s 101 Damnations

Whilst writing the EJB modules for our JGenerator product, we started punting an email back and forth containing all the issues we had with EJB. And there were many. Before we knew it we ended up with 101 howlers.

This is an old document, one that I just dug up. Some of the points are valid, some less. But it all adds up to one thing: EJBs are often used as the wrong solution.

Jakarta-Taglibs: Input Tag library

The “input” tag extension library lets you present HTML

Extreme Programming problems

This is a long article, and I admit I had trouble getting through it. I believe the author has some points worth mentioning, but fails to really grasp a major aspect: That XP is not for every project or team or situation.

I am a huge fan of XP for many reasons. Each methodology addresses a unique set of problems or issues. XP addresses two main issues: Change and the Risk associated with it. XP attempts to mitigate the risks of changing the system.

If you are lucky enough to be on a project where the customer can clearly articulate their requirements once, then maybe XP isn’t right for you. From experience, most customers in the e-business arena, don’t know what they are building. Some don’t even know the problem they are trying to solve. XP, then, is a great way to tackle the problem.

Again, choosing the right methodology is not easy, but understanding the potential problems of the situation will help in picking the right one. Understand when XP is good, and understand when it’s not. But don’t try to change XP into something it’s not, when all you needed was a different process.

P.S. A personal gripe. I’ve seen these types of arguments against XP before. They usually come from a person that feels threatened by the process. This person might fancy themselves an Architect, one that sits on the mountain and dispenses Beautiful UML Diagrams down to the people. XP completely removes this type of position from the team. It spreads it out, valuing an emergent design over one that is dictated.

Fundamental Problem with Extreme Programming

"XP requires too much of an investment from the business."

I disagree with that statement completely. XP allows the business do what they do best: solve business problems and be in control of the software deliverable.

If the business doesn’t know enough about the problem they are trying to solve, then the project will never be correct. It doesn’t matter how good the programmer is, if the customer doesn’t know what they are trying to accomplish, then the project is doomed.

Of course, the question of “How to technically solve the problem” is up to the programmer.

XP is good because it acknowledges the customer is a participant in the process of developing software during the entire process.