Monday, August 30, 2004 - Posts

MSF Agile – Joy!

A beta of Microsoft Solutions Framework (MSF) Agile has been released and it looks very promising. In its earlier incarnations, I’ve regarded the framework as a kind of best-of-both-worlds combination of the Rational Unified Process and the Dynamic Systems Development Method (DSDM), both very formal methodologies.*
During the last couple of years Extreme Programming (XP) and other loose-sleeved approaches have become increasingly popular. Personally I’ve never been a huge fan of XP. I like the idea of the product, namely code, being at the center of the universe opposed to RUPs motto that “all activities must be balanced to have a successful project” is appealing. I’ve always found the RUP motto a bit odd, what things you do won’t make a project successful it’s rather how you do things.
Pair-programming has never been my cup of tea. Two minds may think better than one, but I get the most and best work done on my own, music playing in the background and without too many interruptions.
The formal camp has clung to high ceremony processes arguing that these give high predictability, sound architectures and a disciplined team. On the other hand the agile cowboys claim that customer involvement, constant feedback and motivated teams are keys to success. I believe the golden path lies between these two and I feel that Randy Miller, the architect behind MSF Agile, has drawn this path on the methodology map.

What I like the most about MSF Agile is that it is simple. It only defines five roles, a clear definition of the tasks for each of these roles, the workflow for the tasks and clearly defined set of work products, but most of all; unlike XP, the framework does not have any rules for how you should work.
Microsoft Visual Studio Team System will have a number of adaptable features to support the MSF processes.
Another thing I like is that even though Visual Studio Whitehorse supports UML modeling, this does not seem to be part of the MSF process. This is good since modeling is nothing but a tool. In some projects large class diagrams is the way to go, but in most RAD projects a quick mock-up on the whiteboard gives better results; after all the role of diagrams, as with any other illustration, is to improve understanding.
The build system in Visual Studio 2005 is neither a requirement for the process, but it comes through pretty clearly from development process descriptions that such a tool should be in place.
Continuous integration is one of the most important elements of successful agility.

As a consultant I always have some skepticism towards any nostrum methodology, but I will champion those who offer true agility and freedom. MSF Agile is a promising framework; it has the agility of XP without the stupidity of XP. And just like RUP it has well defined artifacts without the complexity. Combined with discipline towards design guidelines, automated tests and continuous integration MSF Agile is compelling.

* MSF Formal will still be an option for large scale traditional projects.

posted Monday, August 30, 2004 9:45 PM by anoras

Book review: “Better, Faster, Lighter Java”

First of all, don’t let the title scare you. This book isn’t really about Java, it’s about simplicity and when it comes to simplicity language is not an issue. J2EE development has become cumbersome as programming frameworks and specifications have bloated over time. The .NET community has lessons to learn for these problems to avoid similar pitfalls and improve the way we develop software.

The gospel is well-known, the authors speak warmly of agility and they lay out five basic principles that will make your projects simpler and hence more agile.
In the first principle is something you’ve heard hundreds of times, “Keep it Simple”. I believe this is an important point because it is far from simple to keep things simple. Tate and Gehtlands message is to avoid complexity by all means possible, not to be afraid of refactoring and to setup a safty net based on common tools such as NUnit.
The second principle is “Do One Thing, and Do It Well”. This is about understanding the problem you’re trying to solve.
The third principle “Strive for Transparency”. If I have to pick a favorite, this is it. The principle core message is to keep the business model simple and maintainable. The book shows how to separate generic services from the domain model and keep it clutter free.
The fourth principle is the classic “You Are What You Eat” which means that every tool, library or similar you use becomes a part of your project and your way of writing code.
The final principle is “Allow for Extension”. Here the authors show techniques for loosening up your architectures and enabling unplanned future changes.

This is not a book where most of the pages are filled with source code. There are some code examples and all of these are easily accessible to developers with some C# experience.
In addition to that, all of the frameworks used throughout the book have been ported to the .NET platform. These include Strus.NET, NHibernate, Spring.NET amongst others.

The Microsoft platform is not immune to the bloat the Java community tries to tackle. After all, .NET itself was motivated by the ever growing complexities of Windows DNA development. If you’re unconscious about bloating frameworks and applications you will get stuck. This book shows lays out five simple principles for avoiding bloat without sacrificing efficiency and still being able to develop high-performance applications that address complex business problems.
This is one of the best .NET books published this year and it is highly recommended!

posted Monday, August 30, 2004 7:09 PM by anoras