Sometimes it seems that we simply go from one extreme to another. Once upon a time developers didn’t bother to write tests. Everything was tested manually. When changes were made the whole thing would need to be manually tested again. Sometimes we used test scripts, other times we just played around trying to break functionally. And then we couldn’t remember what we had done to break it! Managers would roll their eyes in frustration when developers talked about writing unit tests.
Sometimes we forget how much old software is out there. We talk about the software industry still being young and perhaps quite immature, but actually, word processing software started reaching offices in the early 1970s - over 40 years ago. The first version of PowerPoint was released in 1987, public use of the internet began in 1989 and then exploded during the 1990s. Looking back it is striking how much has changed in a short period of time.
On 19th March Gordon and I attended a 2 day agile coding retreat in St Austell, Cornwall. Hosted by Kevlin Henney and Jon Jagger the retreat was organised for developers to discuss, practice and improve their software craftsmanship, communication and creativity. Having personally never attended such an event before I was interested to see if there was an opportunity for me to hone my programming skills to ultimately improve my performance as a developer.
I was working with a company recently where we were using Xunit as our test framework, NSubstitute for mocks, stubs etc and we ran our tests using NCrunch whilst developing in Visual Studio. At one point during the project we noticed that some of our unit tests were failing intermittently. This is more common in longer running integration tests but not so common in unit tests. When we do see this behaviour in unit tests the cause is often shared state being accessed when unit tests are being run in parallel.
I first learnt about writing unit tests following a project where we missed the deadline and spent far too long fixing and then refixing the code. I became frustrated that we would fix one thing and then something else would go wrong. When I saw how tools like NUnit and Rhino Mocks gave me the confidence to fix bugs and refactor it genuinely changed my working life. On my next project I determined to write tests as I went along and to be honest I’ve never looked back.
Like me haven’t you at times been frustrated by software that has been delivered late and not made the business impact you expected. A lot of time and money had been wasted due to assumptions being made with inadequate requirements; poor communication of team objectives and an overall lack of understanding, focus and misalignment with the overall business goals. As a developer I use interative delivery and this places emphasis on integrating learning from delivery and refining the scope and requirements.
Over the years I’ve worked on lots of teams. Some good, and some not so. But what is it that makes a team successful? There are the obvious things like the kind of people you have on the team. If the team members just don’t get on, if they don’t have the skills required to do the job, or they just aren’t interested in working hard then it’s clear the team will suffer.