Ayende gives an example of how to set the bar high. The broken windows theory talks about what happens when you let your guard down. In software this means that if you start setting the bar low, for example allowing more bugs, or stop refactoring for a while (because now is not the right to
Oren Ellenbogen writes about TDD, testability and Scrum implementation in his team. Very interesting. The way I react today to untestable code makes me realize how far I’ve become as a developer. So far off than the “just-make-it-work” manager I used to be.
My last post reminded me of another thing that came up during the last audit. The code review process was just beginning, but I already had forms as proof of the process taking place. The auditor looked at them and asked “why aren’t there names on the forms?”. I said proudly (as it was my
Today one of the developers asked for a meeting with me to discuss some design issues. It’s been a while since I did one of those, but was very entertaining for me, and helpful and productive for him I hope. At the end of the session, I reminded of a question that came up during
This is something that I used to hear from the developers. I bet I used it as a developer and then I got a change to use this phrase today. I have a small task scheduled to run on a server to collect bug information. It ran every day at 3am, until a month ago.
In the beginning it was dark, and procedural. So for instance, if you wanted feedback on a feature, you would either communicate it verbally, send screen shots, or wait for the release. Then the managers rebelled. We saw the obvious problem here – our customers needed to actually use the software to give feedback, sooner
One of the processes we were planning to introduce was some root-cause analysis for things that happen along the way. As luck would have it, one of the project managers came to a conclusion he needed something like that today. A bug that was discovered was the trigger, and the three team members involved were
One of my greatest decisions ever (in my view, anyway) was on a project I managed a few years back. Under pressure, and no time to waste – sounds familiar, I know – all we could do is produce more bugs. I asked the test team lead to assign testers to developers, to sit with
This number surprised me. In all 3 projects (every project has a different size, complexity and team) there’s a 75% rate of open non-reproducible bugs. What does this mean? I know we’re not doing enough to reproduce bugs. I take that as a given. I also think that since it’s more easy to fix reproducible
During the management review, we discussed the fact that although there’s extensive testing, critical bugs slip through. One of the PMs, who is a big proponent of exploratory testing, said we’re concentrating too much on writing test procedures, and less on testing. I did actually produce the numbers, thanks to the newly implemented MS Project