UnitOfWork

The last 15 months I have worked as project manager, system architect and competency trainer at Transsoft A/S.

When I was hired, my task was to implement transparent project management, which would allow the board to know what development was doing and how the project was progressing. I also had to implement practices, which would empower the team to deliver software of a verifiable quality level.

ERP software is supposed to last many years, often 10-15 years. This means, that it must be built to be maintainable, and it must have a very extensible and flexible application architecture, which allow for easy implementation of customer specific busines rules and views.

In order to deliver a system with the kind of progress transparency and quality of architecture demanded by the board, I had the following agenda:

• Raise the general team skill level by introducing a common understanding of application architecture (appropriate for our domain),
• by teaching software engineering practices and
• by implementing agile project management.

Concretely:

• Implement Scrum for project management
• Teach the patterns and concepts of Domain-Driven Design to ensure a common understanding of (a) fundamental application architecture
• Teach common software design patterns and principles (SOLID among others) - again to raise the design awareness of the team
• Teach and implement several XP practices among them Test-Driven Design (and the practice of mocking) and later Behavior-Driven Development with a focus on user stories and executable specifications in the form of acceptance criteria

All these elements are needed in some form or shape, to deliver the kind of software we write. But the test-suite, that is the result of test-first development, is to me, the most important element, to ensure a steady progress and a certain level of quality to the code. A Lot of Good Things emerge when you do Test-Driven Development/BDD that I will not reiterate here,

The last few months I have spent a lot of my time developing a course department in Transsoft. This has had the consequence, that I haven't had the same focus on our practices and quality of the code, that I had before. My lack of focus on our practices have resulted in a rotting test-suite.

After a major refactoring (that I gave the greenlights on), our tests were not kept in synch, and we could no longer rely on them. This has reduced the confidence of the team, as we can no longer run all our tests and know, that adding a new feature or removing a bug, has not changed the expected behavior of the system. In addition, the test-suite is now technical debt and does the exact opposite of its intention - it reduces confidence instead of reinforcing it.

We have changed our sprint plan to give the developers time to refactor the tests to get in synch with the codebase. We also did a brush up on our DONE DONE DONE definition as well on why we use the practices we do. But this work takes time, velocity is reduced and refactoring 500+ tests is a pain.

So my advice to any team practicing TDD or unit-testing is to NEVER, EVER ALLOW YOUR TESTS TO ROT!

Labels: Anti-pattern, BDD, Best practices, TDD

I was recently interviewed by Søren Spelling Lund from Århus .NET User Group to their ANUGCast on the subject of Test Driven Development.

The interview is in danish and you can listen to it here.

Labels: ANUGCast, TDD

Today I participated in the Test-Driven Development tutorial hosted by Robert C. Martin from Object Mentor. I paired with an experienced dutch developer and through a 6 hour intense code 'sprint' we build part of a game, Hunt the Wumpus, using TDD - unit tests, acceptance tests (Fitness), mocks and pair programming. It was an intense and difficult experience. I've read quite a lot about TDD and have used it on two minor projects, but todays tutorial has convinced me I need to make the transition entirely to TDD practices as soon as possible.

Labels: Pair Programming, TDD

I guess every developer at some time finds the urge to write her own (faulty) implementation af an O/R mapper. This time has now come for me.

Let me make it clear: There are very good O/RM tools on the market already (for example NHibernate and SubSonic to name a few that I have used myself) and my attempt will most certainly be feeble in comparison with most open source and commercial projects. But that is okay, because this project is about learning, not the product that may or may not emerge during the development process.

The objectives of the project are:

• Gain better understanding of certain design patterns, in particular
  
• Domain Model (Domain Logic Pattern)
  
• Data Mapper (Data Source Architectural Pattern)
  
• Unit of Work, Identity Map and Lazy Load (O/R Behavioral Patterns)
  
• Identity Field and Foreign Key Mapping (O/R Structural Patterns)
  
• Metadata Mapping and Query Object (O/R Metadata Mapping Patterns)

• I will be using Test Driven Development and the NUnit tool for testing in this project (or perhaps http://testdriven.net I don't know yet). I have read quite a bit about TDD but have never used it intensively throughout a project, so this will be entirely new to me.

I'll be setting up a subsite, http://archeion.unitofwork.dk/, where you may follow the progress (or regress) of the project. I will appreciate comments on the work and should you feel so inclined you may even join the project as long as you accept that it is a learning project, not a product project. All code and documentation will be free for download and may be distributed and modified at will.

I had to find a name for the project, a name that carried an inherent meaning that would at least hint at the work an O/RM tool does for you, so I ended up with the ancient greek word for Archive:

Archeion – government palace, general administrator, office of the magistrate, records office, original records, repository for original records, authority.

I'll be using Visual Studio 2005, SQL Server 2005, ASP.NET (or perhaps Castle Project MonoRail, I have not decided yet) and C# for this project.

I'll be using the following litterature:

• Patterns of Enterprise Application Architecture by Martin Fowler (ISBN 0-321-12742-0)
• Test-Driven Development in Microsoft .NET by James W. Newkirk and Alexei A. Vorontsov (ISBN 0-7356-1948-4)

Labels: Learning, Litterature, Patterns, TDD