I had this conversation with some friends on Twitter about a month ago and have been thinkinng about it ever since. We are all professionals, but professional what?
I have come to the conclusion that I am a problem solver. That’s my business. Whether its process management, software architecture, personal growth for my development team or trying to keep my daughter from stealing my son’s toys, I solve problems. Software development is my tool (except for the stealing part. I use my daddy voice for that).
One thing I have learned from BDD is that developers spend too much time thinking about technical implementation details rather than the problem at hand itself. I am continuously working with my current team to get them all to adjust to this way of thinking: think about the problem. What are we trying to do? We’re not trying to write software, we are trying to provide value to our customer, and we achieve that through software. Adopting the context/specification style of testing has helped me evolve even more into a digging into a deeper understanding of what the problem really is, what context does the problem apply to, and what are the specifications that are proof to show that a solution can be demonstrated? You MUST think about these issues before writing any code, and too many developers just want to code without fully understanding what the problem is. ONLY when you fully understand the problem, can duplicate the problem and demostrate it with specifications, can you start thinking about technical implementation. Naturally, you have to have some sort of roadmap, an idea for system architecture, think about non-functional requirements, and that’s all expected and necessary. But when it comes down to coding a piece of behavior into a system, too many developers are still just jumping in and coding. Even when writing unit tests, developers are thinking about the techinical aspects of the system and often write poor unit tests. I’ve been there. This is why I feel TDD is an ancient and outdated craft. TDD does not do enough to force developers to really focus on the problem and gain a full understanding of it prior to coding. I feel BDD helps achieve this.
I haven’t posted anything on what I’m doing with BDD because you can search CodeBetter for it and find information from several of the bloggers, all of whom I’ve spent a considerable amount of time with to help me evolve to be a better problem solver, by way of writing software.
We need to focus on the problem at hand, and let the technical details and implementations evolve from specifications and that demonstrate the problem. C# is easy. Correctly solving the problem your customer is having and delivering the appropriate behavior is much more difficult, so there is where your time needs to be spent: understanding the problem. Once you fully understand what you are trying to deliver and have specifications within context to demonstrate this, the technical solution will be clear, simple and right in front of you. Let it evolve from that. The technical implementation is secondary to the understanding of the solution.