Dark Matter and Black Holes
Just watched an interview with David Anderson, formerly of Microsoft.
In addition, you can go to his blog where you can read about something he calls Dark Matter. I find it funny, since I’ve been talking about something similar for years - something I call black holes. In my definition, every project has at least one black hole – which is something you can’t see into. In a project, a black hole could be a reflection of quality or certainty. Ask your team “how many bugs will you have in this project?” and you will be left with blank looks or a whole lot of “pffts’s” – that’s a black hole. Every defect found results in work. You can’t estimate the number of bugs on a project or the effort to fix – therefore, every project has a high degree of uncertainty determined by certainty and quality. Black holes
You can’t get rid of black holes, but you can try to shrink them by scattering your project with things you can estimate or have higher certainty. For example, you can estimate how long it takes to write a unit test on an object with fairly good certainty. We know that the more unit tests we write, the less the possibility we let bugs we introduce as a result of change into builds – because we can catch them early. We know that if we catch bugs early, they take less time and effort to resolve – this reduces the black hole.
Technology is riddled with uncertainty, mostly because of the rate of change of the platform and technologies we work with. I’m not saying that we should NEVER change how we work, but we can invest heavily in internal education and cross pollination of skills to reduce uncertainty. You should leverage skills throughout or from outside of your organization to help architect, design, and plan versus review – since, by the time you perform code and design reviews, its likely too lake. Make sure your teams have every resource you can realistically provide to keep everyone educated and up to speed on all new technologies and techniques.
I’m a believer that you should also consider adopting software factories - for all of the reasons I've just mentioned - quality and certainty. Do you ever debug the code generated from the winforms designer in Visual Studio? Well, some of you may – but the majority of you just assume it all works. The winform designer (a mini-code generator) is a much more consistent coder than most humans and it would be foolish to simply write all the code by hand these days. Use tools that generate code – because these tools will do this more consistently and repetitively than any human can. If your code generation tool introduces a but – you fix the code generator – and that bug won’t get introduced again. Now, software factories are much more grand in concept than a winforms designer - but you get the picture..