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!

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.

Good article

---------------------

http://www.bodycraftny.com

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.  

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.

You've been kicked (a good thing) - Trackback from DotNetKicks.com

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.

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.

Pingback from  » Daily Bits - December 28, 2007 Alvin Ashcraft’s Daily Geek Bits: Daily links plus random ramblings about development, gadgets and raising rugrats.

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  

Pingback from  links for 2007-12-30 | Lazycoder

Pingback from  Problem Focus at  Fragmental.tw

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:

activeengine.wordpress.com/.../clarity-of-thought-only-comes-from-practice

AJAX ASP.NET AJAX Control Toolkit - Basic Sample For DynamicPopulate Control [Via: alikl ] ASP.NET ...

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.

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.

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.

Pingback from  TechMount  » Archive   » Daily Friction #311

Pingback from  129568.nant.codebetter.com/.../are-you-a-problem-solver-or-a-developer.aspx

Pingback from  The Daily Grind 1304 | Games Infomation