I think in the end it was quite successful and offers a pretty robust implementation of version 1 through 5 UUIDs, including a version 4 UUID which is compatible with the native System.Guid implementation. There is one class called Uuid which can represent any version of UUID, and it is used similar to the aforementioned System.Guid to either create a new unique identifiers or represent existing ones. It also supports explicit casts to/from System.Guid.

Uuid existingUuid = new Uuid("9b1ea5f8-702b-4ad5-97f0-34bb10a28602");
Uuid newUuid = Uuid.NewUuid(Uuid.UUID_VERSION_1);

A battery of unit tests is also included to help verify the implementation. You can download the code from my Code page as usual.

[RestWebClient(Url = "http://local.yahooapis.com/MapsService/V1")]
public interface IYahooTrafficService : IRestWebService
{
    [RestNoun("trafficData", Method = RestHttpMethod.GET)]
    [return: RestReturnType(RestReturnType.Xml)]
    XmlDocument GetTrafficData(string appid, string street, string city, string state);
}

The example here uses the Yahoo Traffic Data API. Once the interface is created, I can get a concrete instance through the RestWebClient factory:

IYahooTrafficService svc = RestWebClient.Create<IYahooTrafficService>();
XmlDocument xdoc = svc.GetTrafficData("YdnDemo", "1771 LBJ Fwy", "Dallas", "TX");

And voila! Traffic data:

Example of output from the Yahoo! Traffic Data API.

Pretty simple, and it works with a variety of REST interfaces. It can also handle complex types through XML and binary serialization as well as straight binary streams, such as image files. The server piece works similar to the client; decorate a class with attributes to describe the service contract, and an HttpHandler does the rest.

This was particularly challenging on the client piece because I had to learn the System.Reflection.Emit namespace, which I had never used before, and it requires an in-depth knowledge of MSIL. So that was difficult at first, frustrating most of the time, and rewarding in the end.

At some point I would like to clean up the code and release it as open source. Some other folks might actually find it useful. It definitely needs some heavy refactoring first, though.

In my experience, the one largest source of waste that can be eliminated or reduced to add immediate benefit to a project is rework¹. Rework falls into two major categories:

• Technical debt
• Defects

Technical debt refers to those shortcomings in the design of the software that we accept that we will have to address at a later date. This often comes as a result of running out of time in any given iteration; as we cut corners, quality suffers, and technical debt mounts². Defects, on the other hand, are unintended consequences or misunderstood requirements; that is, they are unforeseen problems with the software that must be addressed immediately. The ratio of the two varies from project to project, but since defects often require immediate consideration, they tend to have a disproportionate effect on the deliverable date.

Of course, the obvious solution is to write bug-free code. That’s what we want to do anyways, right? Admirable, yes, but not practical in the least. It is impossible to write code that is free of defects, as it would at its very base require a product owner and development team that are somehow psychically linked as well as infallible. However, it is possible to reduce the number of defects by following some very simple principles. This list is by no means comprehensive, but it should give you a starting point.

Limit work in progress. Each developer should really not be working on more than one or two tasks simultaneously in most situations. Focus increases reliability.

Reduce “crunch.” It should be obvious at this point to both developers and managers that there is a diminishing return on hours worked. Try to take on realistic commitments for each development iteration and avoid working large amounts of overtime if at all possible.

Pair programming. This is a highly useful tool not only for developers to check each other but also a developer and a quality/business analyst to check each other. Your team will think you’re weird at first for asking for such an odd pairing, but I’ve done this before, and it can be highly valuable to have someone who understands the business and requirements working with the developer up front. This also increases utilization of QA resources that often sit idle until the end of an iteration.

Engage QA earlier. Frequently in agile environments we fall into the trap of doing “mini-waterfall.”³ That is, we do a design and specification phase during sprint planning, then the coders spend a bunch of time doing heads-down work to meet sprint objectives, and then they finally throw their deliverables over the wall to the QA team at the very last minute. If you find this to be a frequent problem, then break your tasks down into even smaller chunks that can be completed and delivered without utilizing the entire sprint for each one.

Inclusive design. Always strive to include the entire team in design and specification meetings. It’s a simple fact that if more people are involved, more problems are likely to be uncovered before development even starts. The team as a whole should have a keen understanding of the entire project, even parts they may not be responsible for. If you find that this inclusiveness is eating up too much time, it’s most likely because your team is too large or your meetings are not staying focused.

Daily updates. The daily status or “stand up” meeting is one of the core principles of Scrum. Even if you’re not practicing Scrum (or any agile methodology for that matter), I highly recommend daily updates. A focused, repeated meeting to keep everyone up-to-date on the team’s progress can help the team be aware of its progress as a whole as well as help identify and address problems mid-stream rather than at the end.

Visibility. Another principle of Scrum, task boards and burn-down charts can also help the team with understanding where it is. Whatever the actual implementation, it should be a highly visible cue into everyone’s projects and the overall health of the project. Increased visibility reduces one of the most frustrating defects—items that we just plain forgot about.

We can think of a differential update as a prediction followed by a correction, a kind of guessing game.  In its simplest form (just bsdiff / bspatch), the client has only a dumb guess, ‘original’, so the server sends a binary diff to correct ‘original’ to the desired answer, ‘update’.  Now what if the server could pass a hint that could be used to generate a better guess, but we are not sure the guess will be useful?  We could insure against losing information by using the original and the guess together as the basis for the diff…

This system has some interesting properties.  If the guess is the empty string, then we have the same diff as with plain bsdiff.  If the guess is perfect, the diff will be tiny, simply a directive to copy the guess.

A predictive software update engine has some interesting potential. I would love to see with what kind of accuracy their algorithm can actually “guess” the correct patch.

As with all things, the answer is “not always.” With my current project, the temptation is high. The organization and the project already exhibit several agile/XP qualities:

• Continuous integration.
• 30-day release cycles.
• The project has already been broken down into smaller chunks of deliverable features.
• We do daily status meetings. (Although they are an hour long and much less focused than a daily stand-up.)

As you can see, it has the potential… on “the cusp of greatness,” you might say. It would be tempting to think that we could just overlay Scrum or some other form of iterative development and succeed, and trust me, it is very difficult to resist that urge to evangelize Scrum. However, there are several factors that mean I must take a healthy dose of reality first:

• The organization has no agile history, and I would bet that 99.9% of the managers and developers have never heard of agile development, let alone practiced it.
• The “product owner” currently lacks the discipline/desire to commit to a set of requirements for any length of time. (We would be aborting sprints right and left.)
• Policy prevents us from actually working on anything until it is completely designed and documented. (Of course, the policy is not always followed 100% of the time.)
• The developers are not accustomed to self-managing.

Those are just a few off the top of my head. As you can probably imagine, trying to throw Scrum into the mix here would not work out so well. On top of the above hurdles, it would be a hard sell to management, and I have a feeling any initiative would be quickly abandoned if positive results were not immediate.

Still, that doesn’t mean I’m not going to try at some point. I just have to be subtle and introduce things one step at a time rather than going whole hog from the beginning.

1. Regular Delivery
2. Quality
3. Active Stakeholder Involvement
4. Scale
5. Teamwork

I was thinking, though, that the list was far too specific. Some of these things are results of similar disciplines—for instance, Active Stakeholder Involvement and Teamwork are both principles of good communication. Others are esoteric, such as Scale.

I decided to reorganize these disciplines a bit and change them around, hopefully making them more broadly applicable to agile processes. Below are what I believe to be the disciplines of an effective agile/lean project.¹

The Discipline of Adaptability
How can you talk about agile and not mention adaptability?

The bottom line is that for agile to work, your stakeholders and your team must (willingly) be flexible. No set-in-stone product design, no hard deadlines, no non-negotiable items. An agile project is a conversation, not a lecture.

The hard truth is that everything changes, especially software. If people are not willing to adapt to a changing environment, then agile will fail before it even starts. The team and the customers must be open to receiving change and handling it appropriately.

The Discipline of Intervals
One of the foundations of an agile process is the idea of time-boxing. Time-boxes are important because they allow us to control the pace of development even as we are constantly responding to change. Iterations and releases are often time-boxed to 30 days. The daily stand-up meeting is time-boxed to 15 minutes. Research and discovery tasks can be time-boxed to a few hours so that they remain focused.

When you stick to regular intervals, it assures your stakeholders that even without deadlines they will get something they can use in a reasonable time frame. Every 30 days, you will get some piece of functionality. It also increases developer productivity by setting a pace for development rather than racing to meet an arbitrary future date. When you produce incrementally, you can avoid the impending death march of waterfall projects.

The Discipline of Completeness
Hand-in-hand with intervals, completeness is an important factor in delivering functionality to your stakeholders. Each interval, the team commits to complete a predetermined set of features. At the end of the interval, the team does not deliver partial functionality or a bunch of mock-ups²; they deliver working software.

The duty to completeness is not just for the developers, however. The product owner is also responsible, and thus he must be willing to de-feature when appropriate. If it looks like a commitment will be missed, this should be communicated to the stakeholders and the feature moved to a future iteration. The product owner should never³ force the team to deliver more than it is capable of in a single iteration, and the team should never arrive at the review meeting and have to tell the stakeholders that they could not get something done.

It is also important on an individual level that each team member not claim that a feature is done until it is truly done—that is, it has been coded, tested, signed off by the product owner, and delivered to the customers.

The Discipline of Quality
One thing that agile development will uncover very quickly in a software project is any sort of fragility. In order to respond to constant change (see “The Discipline of Adaptability,” above), the code must be resilient enough to withstand it… or it must be brought up to that level if it is not.

A common misconception of quality assurance is that QA’s job is to find bugs. On the contrary, it is actually there to prevent them. Many products have a very long QA cycle because so much time is spent fixing defects that have been identified. Imagine how much simpler it would be if there were no defects to find!

This requires a great deal of discipline from your engineers, since they must be mindful of QA from the beginning. As the saying goes, “Do it right the first time.” Developing in increments and utilizing practices such as Test-Driven Development will help achieve this goal.

The Discipline of Communication and Transparency
Communication and transparency are absolutely critical to an agile project. Since there are fewer document artifacts moving around than in a waterfall environment, it is very easy for an agile project to operate “under the radar” if the team is not careful.  This is why processes like Scrum have the important core meetings: the daily stand-up, the review, the retrospective, and planning. The task board is also a great visibility tool.

It is important that the Scrum Master and the product owner work together to ensure that communication flows freely between the team and the stakeholders. Without this channel, the stakeholders will feel left in the dark about the project’s status, and the team will feel like they have no guidance or feedback.

The Discipline of Innovation
The final discipline on my list (but certainly not the least) is innovation. In order for an agile project to succeed, the team and the process must constantly improve. The retrospective allows us to reflect on our past performance and adjust for the future. The team’s velocity is a tool to help us measure and increase throughput.

The most important thing to keep in mind is that no process is sacred. You may have read all the books on Scrum, but if “pure” Scrum is not working for your team, change it. Maybe you need shorter/longer iterations? That’s fine. Maybe you need a traditional project manager in addition to the Scrum Master and product owner? That’s fine too. Do what feels right for your organization. Experiment. Learn. Grow. Innovate.

Agile Development Projects and Usability by Jakob Nielsen

If I didn’t know better, I’d say he has some disdain for Agile, but he makes some good points on how Agile can threaten a project’s user experience.