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