This article was moved to MDriven Wiki – Different types of bugs
The typing-bug : You did not actually type the things you wanted to type
The code-bug: Your code does not actually do the things you intended it to do, but it was typed correctly
The think-bug: Everything came out just as planned – but now that you see the result you find that you planned the wrong thing
The code-bugs are managed with unit-tests which in short is to explain what you expect your active code to do with some more test code.
The think-bug – the only practical way to manage this kind of bug is to increase the development speed so that you can verify your thoughts quickly – learn, tweak and move on, over and over. This is where model driven development shines.
Clients and employers that pay for developers and coders should make sure that the only bug the developers are engaged in are think-bugs.
The Think-bug is the only kind of bug that gives value back to the domain issues we are set to solve – the other types of bugs is just a result of crappy tools and sloppiness from an immature field of engineering.
Model driven development as delivered with ECO raise the quality by being declarative in every aspect that involves your business objects – and thus nil out typing-bugs and code-bugs. It also raise the speed of development so that the think-bugs can be managed swiftly and elegantly.
In the 90’s
Earlier it was believed that the think-bugs could be avoided by a very detailed analyze phase – here we find the traditional water-fall methods like Rational-Unified-Process (RUP). But now very few software engineers back these ideas. The think-bugs often does not originate from a poor understanding of “now” but rather from an enlightenment of “how it should be” that grows slowly as a project progress. And this is why SCRUM and Agile strategies are so much better at software development – they have room for dealing with think-bugs.
Using model driven tools like ECO enables you to be truly Agile – not only are the tools at their best when we need to deal with the late changes that the think-bugs often are – but developers have a tendency to defend a solution they invested in (as all humans do) so having tools that minimize the investment done gives us developers that are open for change and can reason about the think-bugs without being defensive – this is key to solving think-bugs.