Jose's Blog : Agile

Creating a Customized Guidance Repository

josealmeida — Fri, 19 Sep 2008 04:55:00 GMT

As a consultant part of my job is to provide guidance to our customers on the best way to use our technology, namely in terms of application development practices. Over time, you start to better understand the type of customer you’re working with, what works, what doesn’t and you start to optimize your own delivery processes. You reuse material and refine it the next time around. That’s the nature of our work in the Services organization.

Lately I’ve been involved in several engagements in the Application Platform Optimization space, mainly the Application Lifecycle Management suite of Offerings.

At the present I’m working with one customer who has gone through the Assessment phase and we’ve arrived at a six phases maturity growth roadmap that they’re starting to implement. One of the key aspects of this type of custom engagement is that all the experience gained by the customer and all the guidance delivered by the consulting team, should be persisted by the customer. We’re working with a small team within the customer and they are the ones who will have the responsibility of creating their own guidance and internal best practices and sharing all this information with the rest of the organization. So to collect, persist, distribute and, later on, update their in-house customized guidance for application architecture, development and lifecycle management, we’ve chosen to use the Guidance Explorer tool available on Codeplex.

The use of this tool turned out to be a great fit for this scenario. Instead of compiling one giant document, that would go through several versions and would quickly fall out of synch, the customer is now publishing and updating guidance, based on an existing database of industry and technology best practices. Guidance articles have their own metadata, the lifecycle of each piece of guidance is independent of each other and, if needed, all the guidance can be compiled into a Word document for a hardcopy reference. Additionally, one of my favorite features is the ability to subscribe to the guidance through a published RSS feed and receive a notification whenever guidance changes or a new best practice is published.

Economics of Agile Software Development

josealmeida — Wed, 17 Sep 2008 04:12:08 GMT

Dr. Laurie Williams has been a long-time researcher on Agile methods and their impact on software engineering.

She and her students have published a number of very interesting papers on varied subjects, particularly on the economics of agile practices, like Test Driven Development (TDD) or Pair Programming.

You can find a list of publications here.

Unit Testing User Interfaces (Updated!)

josealmeida — Tue, 15 Jun 2004 23:13:00 GMT

Usually one of the major difficulties a developer faces when writing unit tests is how to write test code for User Interfaces. This is particularly important when we're doing Test-Driven Development....(read more)

Testable code

josealmeida — Tue, 27 Apr 2004 19:31:00 GMT

Previously I mentioned that one of the most important benefits I get from using TDD is that it drives me to write more testable code. I've been thinking quite a lot about this, and another recent post from Chris Dickens made we even more aware of the importance behind writing testable code.

Chris states:

"As you might expect, before we can start serious development we have to write specs. Those aren't my job (that's what Program Managers do) but developers and testers are actively involved in critiquing the specs. Technically my purpose in those meetings is to flag any design issues that would make the product untestable, but in reality I'm there to provide my input on what the product should do."

I've found (the hard way) that trying to test code that wasn't written with testing in mind, is extremely hard, especially when you find tightly-coupled code.

TDD promotes decoupling and this, by itself, is very helpful in producing testable code, because there's some way to plug into the production logic you want to test. If the code you're testing depends on other parts of the system you can find yourself writing a huge amount of code into the setup methods of the unit tests. This, unfortunately, introduces a high degree of coupling into the testing logic, particularly if the code you're dependant on belongs to another domain (i.e. it's an external system)

Using mock objects can help us develop loosely-coupled unit tests. Considering this, some questions seem to arise almost instantly... "When should mock objects be used?", "Is it recommended to use mock objects to represent every external system that our production code interacts with?", etc.

Here's a definition of a Mock Object:

is easily created
is easily set up
is quick
is deterministic
has easily caused behaviour
has no direct user interface
is directly queriable

From the above definition, it's possible to identify a couple of situations where using mock objects can be valuable in coding unit tests:

the real object doesn't yet exist
the real object is difficult to setup
the real object is slow (if it takes too long to run the tests, you might feel discouraged to run them)
the real object produces unpredictable results which may cause the test to behave in a nondeterministic way;
the real object is a user interface
the test needs to ask the real object how it was used (for instance, the test might need to verify if an event was raised and caught correctly)

Developing unit tests with mock objects, improves domain code by preserving encapsulation, reducing global dependencies, and clarifying the interactions between classes [Mackinnon, 2000].

TDD Adoption Numbers

josealmeida — Fri, 16 Apr 2004 12:19:00 GMT

Matt Hawley posted a few numbers in order to justify/support the adoption of TDD.

I've found an interesting research paper on the subject, from Matthias Müller and Frank Padberg from the Karlsruhe University in Germany.

Some of my personal views on the subject are:

I do find there's a slight overhead to developing Test-First. However all developers unit-test their code, to one degree or another. All developers write some form of test code. I believe the overhead comes, not from writing test code, but from using a testing framework.
IMO one of the greatest benefits I've experienced by coding test-first is that the code I write is testable (i.e. If someone else needs to write/extend test-code, for instance to test some wierd situation, it can easily be done);
Coding flows with much more confidence (more immediate feedback on what's wrong);

I do believe that TDD is a very helpful practice and from my experience, together with other practices like Refactoring, I do believe that it helps to write better code.