Are you a problem solver or a developer?

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.

This entry was posted in Agile, Featured. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

20 Responses to Are you a problem solver or a developer?

  1. saygin says:

    Amen! I won’t say that I’m immune, however very often when talking to someone, I have to stop and say “What is it you’re trying to do?” It’s because I, like you, am a problem solver, and I can only do that when I know what you’re trying to do. If someone is asking for something that doesn’t quite make sense I have this little voice in the back of my brain that forces me to dig deeper and find out what they’re really trying to do.

    http://www.sayginnlp.com

  2. saygin says:

    Amen! I won’t say that I’m immune, however very often when talking to someone, I have to stop and say “What is it you’re trying to do?” It’s because I, like you, am a problem solver, and I can only do that when I know what you’re trying to do. If someone is asking for something that doesn’t quite make sense I have this little voice in the back of my brain that forces me to dig deeper and find out what they’re really trying to do.

    http://www.sayginnlp.com

  3. Jeremy, the point isn’t to skip TDD for BDD, but rather teach TDD in the context of BDD.

  4. I’ve always labeled myself a Problem Solver. Part of that comes from my background doing support, but any interview with any company that’s how I sell myself. Where’s the problem, I’ll fix it, using the tools and techniques at my disposal.

    Good call.

  5. Tad Davis says:

    I’ve always promoted myself as a ‘Creative Problem Solver’ first, and a Software Developer second. It’s important to remember that the computer, SDKs, development environments and our own experience are just tools in our toolbox; they need a task to achieve anything. Defining and understanding that task is our first responsibility. The best code we write is that which we write for ourselves. Based on that, I try to become the customer. Once I have that level of knowledge and understanding I can write the application for myself. BDD plays right into this scenario, but TDD confirms that it works.

  6. Raymond,

    I’d mildly disagree with you or at least urge some caution in terms of skipping TDD for BDD. BDD by no means negates the lessons learned by TDD. The hardest part of either is going to be the design aspect, and the mass majority of those lessons are going to be filed under TDD posts and articles. IoC, cohesion, loose coupling, mocks, stubs are all stuff from TDD that don’t go away or really change in the BDD world.

  7. Alan,

    I’m going to post on that. Yes, TDD is still revolutionary to a lot of developers, but I argue to not start there with them. Go full force and just jump into BDD.

  8. LosManos, it was never said you don’t have to put technical thinking into it, so you’re putting words into my mouth. I merely stated that technical details should be second nature and that more time should be spent understanding the problems and solutions than spent on technical implementations.

  9. Ian, I felt the same way for awhile, but now that I am fully submerged in it, I am reaping the benefits.

  10. This will no doubt raise hackles, but I don’t think you go far enough in your criticism of our community when it comes to providing value to our clients. Having managed teams of developers I agree that there is too much emphasis on the “elegant” and not enough energy devoted to “solving the problem so that you get paid”.

    I had to break up a skirmish between the Agilista dude and the RUP guy to say “put something in a class – I want you to start typing today because we have had the problem defined for over two weeks! Solve the problem, refactor only if you have to.”

    It’s sad that we have to fool ourselves with pseudo physicist terms just to make us feel important so even BEGIN to solve a problem. If we languish like this, the accountants and other idiots will rush to first solution that appears to replace the complexities that the programmers bring to solution. We will lose if we can’t focus on the business and the problems we need to solve.

    There’s a concept in the Project management community called Value Assessment, which requires you demonstrate the value proposition to get buy in for a solution. I have a link to the source in my mid way in my post:

    http://activeengine.wordpress.com/2007/11/21/clarity-of-thought-only-comes-from-practice/

  11. Alan Stevens says:

    Raymond,
    Excellent points about problems solving and means vs. ends. You and I are in perfect harmony there.

    re: TDD, however, I detect and attitude that I have seen elsewhere and have been unable to clearly identify. TDD is still a radical practice in the majority of development on the Microsoft platform. I’m sure that in your experience it is “ancient and outdated” but I assure you that your experience is exceptional.

    By making such sweeping, and I would argue extreme, generalizations, I think you marginalize yourself from connecting with and positively influencing what I call yeoman developers. For the majority of my user group members TDD is uncharted waters and they are the more curious developers in my area.

    Regards,

    ++Alan

  12. LosManos says:

    Yes and no. Concentrating on “problem solving” is correct, especially when it is so easy to dive into nice technical solutions, but we must not forget that as long as the solution is to be deployed on a technical machine we have to put a lot of technical thinking into the solution too.

  13. AJ Croteau says:

    A great article. Not only does fully understanding the problem cut down on the development time, it also allows us to write more understandable code making it easier to maintain in the future when creating the solution.

  14. Ian Cooper says:

    The thing I still need someone to make me comfortable with on the BDD approach is the danger of over-specification. While I am a fan of the test organizing patterns emerging from BDD we have been burned before now with heavy use of mocks to specify how we implement the SUT. I feel that state-based verification is still more robust than behavior based verification. Now maybe someone who has done more BDD (and I do need to do some so as to really grok what the BDD guys are driving at) may be able to re-assure me, but I’m not seeing responses on this issue that have mollified my concerns. I want to believe, but I’m still doubting Thomas on this one.

  15. Robz says:

    Problem solver! I have been saying that I’m a problem solver for years…nice to see someone else come to this conclusion as well.

    I also say we are like actors because we need to think like the customers and know as much or more about the process than the customers themselves. We are like method actors as method actors really become the role they are playing. To best understand an issue for a banker, we should really understand things like investments and how they work, and understand paperwork that a banker goes through.

    If we don’t understand their process/pain, we can’t correctly solve it (automate it/fix it) for them. That and customers don’t always know what all of their pain points are or don’t know exactly what they want. Why would a user not know what all of their pain points are? Have you ever heard the phrase “We’ve always done it this way”?

    If it were up to me, my team would work with (or as) a user of whatever product for which they would be developing a solution. What length of time though? A week? Two weeks? A month? Longer? Preferably long enough for them to really understand the problem domain and have ideas about how to make it better.

  16. John Smart says:

    Good article

    ———————
    http://www.bodycraftny.com

  17. Rachit,

    You gave the reason that TDD is outdated. BDD is the evolution of TDD, so why do we need to focus on TDD? Its outdated and a practice that does not fully enforce all that is required to produce good software. In a few years, we may wake up an make the same realization about BDD.

  18. Tim Barcz says:

    Amen! I won’t say that I’m immune, however very often when talking to someone, I have to stop and say “What is it you’re trying to do?” It’s because I, like you, am a problem solver, and I can only do that when I know what you’re trying to do. If someone is asking for something that doesn’t quite make sense I have this little voice in the back of my brain that forces me to dig deeper and find out what they’re really trying to do.

  19. Rachit says:

    I mostly agree with you except “…TDD is an ancient and outdated craft”. TDD is definitely important. Behavior-Driven Development (BDD) is an evolution in the thinking behind TestDrivenDevelopment and AcceptanceTestDrivenPlanning. (as per http://behaviour-driven.org/). My $0.02!

Leave a Reply