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
I’m not that crazy about this, but I’ll play along for awhile. Our flop of the ClearCase implementation has left us with an addiction for the implementation company. In the past I’ve reduced the dependency by transferring knowledge to IT. This worked and now we want to get rid of the on site support completely.
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
I almost cried when I read this. It’s via Scott Hanselman’s blog. Patrick Cauldwell wrote down a list of commandments for the developer. While it is a bit .Net centric, it can be modified to suit everyone. As long their into TDD, continuous integration, refactoring and patterns.