I recently found out that Nester has been released. It's a C# port of Jester (one of my first open source projects).
Jester is a mutation testing tool. It tests test quality by seeing if mutations to your source code cause tests to fail or not. If no tests fail as a result of changing some code then that code might not be tested. It's different to code coverage. All code coverage can tell you is whether your code is executed by the tests; it says nothing about the quality of the tests. You could write tests with no assertions that had a 100% code coverage measure.
I'm thrilled that someone has done this port; I feel it's a milestone for any open source project that someone ports it.
There are lots of code coverage tools but very few mutation testing tools. I'm not entirely sure why this is. Jester is pretty difficult to use, slow to run and the results aren't always very easy to interpret, but apart from that ...
Mary Lynn Manns and Linda Rising have been working on their forthcoming book "Fear Less And Other Patterns for Introducing New Ideas into Organizations" for at least a few years. I first read a draft a couple of years ago (I think it was) and so I was interested to hear their talk. It was mostly an introduction to their patterns for Introducing New Ideas into Organizations. For the first few patterns I was thinking to myself that it was all a bit obvious. Then, as the talk progressed, I thought about ideas that I was trying to introduce where I work and recognised that although many of the patterns that they describe may sound obvious, when you are caught up in introducing an idea then you will almost certainly not think of many of them! Reading through these patterns is a useful reminder; in many respects they are common sense, but, as I often find, common sense is very uncommon.
Ian Hugo was at the first conference on Software Engineering (the term was invented for the conference!) in 1968. He gave a talk reflecting on that conference (and the 1969 follow-up) and looking to the future.
He advised not to push any technique beyond what it's good for; a particularly pertintent comment for an XP conference. XP is great for many projects but not for all. The White Book ("eXtreme Programming explained", by Kent Beck) says what sort of projects XP is suitable for, and it's worth remembering Hugo's advice.
Hugo said that in 1968 there was a "fashion" for throwing large numbers of people at problems; many recognised that this didn't work, and this was written about by Fred Brooks in The Mythical Man-Month (1975), a classic that is still very relevant today. Some problems in software development, that we still see today, have been known about for over 30 years.
Hugo mentioned an interesting experiment (sorry, I don't have a reference for it) where a team produced a Fortran compiler several times. First time, they had a 50% overrun compared to their estimates. On their second attempt they still had a 50% overrun compared to their new estimates, but produced the compiler in 50% of the original time. On their third attempt, they had a 20% overrun and used 50% of the time for the second attempt (I think these were the figures; my notes are a bit rubbish - sorry if they are wrong, but they were something similar). Therefore, overall, although the development team got faster on subsequent similar projects, their estimation, although it improved, was always over-optimistic. This matches my experience too, which is why I like the eXtreme Planning approach of XP; it features feedback so that estimates only have to be consistent rather than accurate.
Hugo mentioned one of my favourite truisms, that has been known since 1968 but still many people don't seem to understand (otherwise, why would waterfall projects still be numerous?). The existence of a software system changes what the customer wants from that software system.
One of the most suprising comments by Hugo was that in 1968 it was recognised that you couldn't separate design from construction of software. My impression of "software engineering" from my University days was that "software engineering" assumed that you could make that separation, so to hear that at the very first conference on the subject it was recognised that you couldn't was interesting. Talking to Hugo afterwards, he clarified that the hardware of 1968 was extremely limited by todays standards; performance was a major issue. Design could not be abstracted away from the actual implementation because performance constraints had to be taken into account for the implementation.
Hugo said that although hardware and software technology have changed enourmously since 1968, people haven't; developers can still only write the same amount of code as they could 30 years ago. The difference is in the level of the code and the amount of libraries etc that can now be used.