This was originally written on March 27, 2007; but for various reasons was not posted until today the 4th of June.
My friend and associate Joseph reminded today that when I posted about transparency I mentioned extreme programming, but did not elaborate on it. To me XP (the abbreviation for Extreme Programming) is second nature so I don’t usually stop and explain it. I’ll take a few minutes to do that now though.
Extreme Programming (XP) is basically a design methodology for software projects. What we have done is taken the basic concepts of XP and made them even lighter for use in web site design. XP was designed for software development which tends to have a longer lifecycle then a standard web site. You can read much more information about XP than I could ever write HERE, HERE or HERE, or just use Google.
Basically though XP calls for a project to be broken down into iterations, which goes through the whole process of software, from requirements, to design, to coding, to testing, to customer acceptance continually instead of waiting until the end. So instead of creating a full specification document and then creating a full design document you do bits at a time, and continually deliver software (or web pages) that the client can provide feedback on. Providing feedback earlier is always cheaper and causes fewer gray hairs.
The basic concepts of XP include:
- Iterative Design
- Client receives frequent small updates
- Ongoing Customer Involvement
- Client feedback is encouraged on an ongoing basis, during development this is usually daily.
- Story Card based Work Breakdown Structure – No massive specification documents
- Requirements are recorded on index cards in a very basic form. Details can then be communicated as needed verbally.
- Daily Stand Up Meetings
- Every morning the development staff meets around a table to discuss what happened yesterday and what is planed for today
- Small Upfront Design
- Structural work on the back end of the site is delayed as much as possible, and only created as needed. This is done to allow for inevitable changes that must be made.
- Refractor Often
- Working code is tweaked to make it run better, faster, and more securely.
- Automated Testing
- Testing is automated as much as possible to allow for easier refractoring.
To deal with implementing XP into a website design company we made a few changes, notably on the timing of iterations. Iterations are usually just a week and a complete release is done within a month, which is four iterations. Of course projects with a longer scope will require additional iterations.
The other area where we have faced problems implementing XP is with the graphic design side of the business. Coding, which as we all know is very hard to estimate, is still much more concrete than graphic design. No matter how talented the designer is (and we have some very talented staff members) the design still must be approved by the client, and is very subjective. Most of our revisions occur at this stage of the project really before any code is written for a web site.
Test fixtures were another obstacle we had to overcome. Testing a website is not as easily done as testing an application programming interface (API). This is an area where we are still working to improve. The solution that would probably be best is to code all web pages using XML/XSLT which makes things much more testable; however on smaller projects this requires too much overhead so we usually end up just testing everything by hand.
If this brief overview was interesting to you then you probably want to read Extreme Programming for Web Projects, it’s a great book and is required reading for all new employees at my company.