Wayne Allen's Weblog

Versioning And XP

This came across the AgileDotNet mailing list awhile back and indicates one of the misconceptions about XP that I run across regularly.

Does anyone have experience of developing web services using agile
methodologies?
I'm in a team who're about to start developing a suite of web services using
XP, and I'm concerned about using an iterative approach to web services.
I'd be grateful if anyone could pass on any information regarding such a
situation - especially any ideas (and documents) regarding versioning.

Here is my reply.

Do you have concerns other than versioning?

 

I assume your versioning concerns revolve around the (wsdl) contract changing each iteration. Realize that even though the goal of XP is to have working software that could be deployed in production you don't have to. That is the point of release planning. There are multiple iterations that make up a release and during those iterations the public interface may change as you discover things about what you're really building.

 

Once you have released your webservice (or any other type of application with a public interface) you need to have a versioning strategy in place irregardless of the software development process used to build the product. It is possible that XP would allow you to release versions faster than some other methodology, but you need to work with other parts of your company (i.e. the customer) to determine when a version should be released.

Public Variables In VB.NET Modules

Interesting bit of detective work the other day I thought I'd share with everyone. A friend of a friend was having trouble with an ASP 2.0 project that was ported to ASP.NET. Turns out that on some web servers the different clients were getting their data overwritten by others. A little splunking uncovered that the application was maintaining state using a public variable declared in a VB module. I could guess what was happening, but wanted to know the details so I created a tiny test app that looked like this:

Module Module1
    Public moduleinteger As Integer
End Module

I compiled and then decompiled the assembly into C# with the following results:

namespace ModuleTest
{
        internal sealed class Module1
        {
                public static int moduleinteger;
        } 
}

So essentially the vb compiler turns the module keyword into the c# equivalent "internal sealed class" and makes all public variable static. Also any refernece to the public module variable gets the "module" name added to it as well. And since static variables are the same across all threads any update to one, updates all.

Presenting at XP Users Group in Portland, OR

I will be presenting "Writing Testable Code: Where XP meets QA"

Are the XP testing practices sufficient to release products to real end users, or does QA have a significant role in XP and how do we as developers assist QA using the XP values and practices.

Tuesday, 7 October. 6 PM. At Novell in Tigard.

http://xpdx.org/