software solutions / project leadership / agile coaching and training

Pulling others up

Posted on June 30, 2009

If there’s one thing that everyone in software development can agree on, it’s that everyone has an opinion on what the best way is to do things. We have lots of books, blogs and articles touting “best practices” and telling us how to do things (and how not to do things).

Often times as a consultant, you are brought into an IT shop where the native developers aren’t using the latest and greatest technology and might not be using the so-called “best practices” that you subscribe to. Usually in these situations, the people that brought you in are bringing you in for your expertise and are expecting you to do things the right way. This can lead to the native developers feeling somewhat threatened.

Recently a friend of mine started at a new client and noticed that the developers there were do most of their data access through dynamic SQL written in their C# code. When he questioned why they did it that way, the developers got defensive, saying things like, “We’ve been doing it that way for years and it’s been working for us.”

While the “best practices” would not recommend you doing all of your data access this way, it dawned on me, this guy is exactly right. He’s been writing his dynamic SQL for years, and he’s been succeeding in delivering working software. So in his mind, he’s not doing anything wrong.

There are two ways of handling this situation. The one that many people choose it to rip on the guy for being so stupid for ever thinking of doing it that way, while saying things like, “No one does it that way anymore”. All this does is alienate the developer and turn them off from trying to learn something new.

The preferred method is to show them that there is a better way. I once asked Andy Hunt how to get people who don’t write unit tests to start writing unit tests. His answer was that I needed to show them what was in it for them. I don’t think he could’ve been more correct. No one wants to do something just because it’s a “best practice” or some smart person said you should do it that way. We’ve all worked with people or seen projects where some “smart” person made something way more complicated than it needed to be and no one else could understand what they did or how to write code using their framework. No one cares if those people used “best practices”, you just hate having to come to work and deal with the mess that they made.

So if you’re working with someone and you think that there is a better way than how they’re doing something, show them the better way. Acknowledge the fact that what they are doing is working for them (they probably wouldn’t be doing it if it wasn’t). Just don’t belittle them for doing it that way, because they may be doing the best that they can.


  1. Pulling others up…

    You’ve been kicked (a good thing) – Trackback from… — June 30, 2009 @ 8:49 pm

  2. Very true. I think one of the great things about our community is that many people genuinely want to help others out. Sure, there’s the egotistical developer every now and again, but by and large, there’s a lot of us that just want to lift other developers up.

    Why? Because most of us remember when we were “That Guy” that was doing dynamic Sql, and along came someone else, or some article that we read, where we were shown a better way to do things. It’s our way of giving back. The better the community is, by and large, the more progress we make as a whole.

    Hudson Akridge — July 1, 2009 @ 8:57 am

  3. Good post. The other thing that I’ll add to Hudson’s comment is that at some level we’re ALL “That Guy” right now! We’ve made a decision to go in some direction and as fast as architectures, methodologies, platforms, frameworks and the like are changing we may not be using the current “best practices”. Business demands that we deliver software within their constraints and spinning in circles adopting this week’s best practice doesn’t get it done.

    Dave Erwin — July 1, 2009 @ 10:41 am

  4. Jon Kruger’s Blog » Pulling others up…

    Thank you for submitting this cool story – Trackback from DotNetShoutout…

    DotNetShoutout — July 1, 2009 @ 11:10 am

  5. Great post, could not agree with you more. Took me a year to convince the rest of the team to do unit testing, and what finally did it was an example of finding number of bugs in one function after writing a simple set of tests.

    Paul Zubkov — July 3, 2009 @ 12:04 am

  6. Let me add a defence of writing the SQL in the class:
    - In most cases the performance improvements of sprocs are minimal and not important for the app in question
    - As long as you use parameterised queries it is just as safe
    - It keeps all the code relevant to the method local where you can view it in one go, as opposed to hunting through for the .sql file
    - It means no-one can change your SQL code under you unexpectedly (e.g. change the sproc to use nolock when it really, really shouldn’t)
    - If you write ANSI standard SQL your code will now automatically work on any database without any porting of anything other than schema

    Sean Hederman — July 3, 2009 @ 4:00 am

  7. Great post Jon! I run into this alot and your final two sentences sum it up perfectly. You have to show them the alternative and how it fits into their style while acknowledging what they currently know and what works for them.

    Thanks for posting this one!

    Chris Deweese — July 6, 2009 @ 8:08 am

  8. [...] Pulling others up [...]

    Jon Kruger’s Blog » Facilitating change — July 13, 2009 @ 1:09 am

  9. Sean, I was about to tell you exactly how lame and ignorant your arguments are, but then I thought about Jon’s blog post and I figure I’ll just hope that someday someone comes along who can show you the right way to do things, and that you’ll listen.

    blindman — July 13, 2009 @ 2:36 pm

  10. The arguments for SQL are solid. We really need context here to make any intelligent assumptions about what constitutes the “best practice.” To that end any developer with experience knows that you must put your personal ideology aside when working with any non-trivial system in favor of what “has been already working.” A lot of time an money has been wasted on trying to move a specific code base to conform to a trendy “best practice” with absolutely nothing but heartache to show for return on investment.

    John Gwynn — July 26, 2009 @ 11:55 am

  11. @John,

    I don’t know that dynamic SQL generated from your code is really that bad. DBAs would probably disagree with you and they might make some good points about how stored procs are better and you could argue about that all day.

    My thing is that if you’re writing code that generates dynamic SQL, you’re probably reinventing the wheel because we have ORM tools that do that for us now. That’s why I tend to think it’s a “code smell” if you’re writing the dynamic SQL generation yourself.

    Jon Kruger — July 26, 2009 @ 6:17 pm

  12. [...] expertise but skilled human interaction and communication skills, and that starts with having an empathetic attitude toward others instead of finding ways to put them down. Share this:Like this:LikeBe the first to like [...]

    Guest Post: The Human Side of Software Craftsmanship | Mashed Code Magazine — January 29, 2013 @ 9:41 am

  13. [...] expertise but skilled human interaction and communication skills, and that starts with having an empathetic attitude toward others instead of finding ways to put them [...]

    The Human Side of Software Craftsmanship « Jon Kruger's Blog — September 4, 2013 @ 9:07 pm

Leave a comment

I have over 15 years of software development experience on several different platforms (.NET, Ruby, JavaScript, SQL Server, and more). I recognize that software is expensive, so I'm always trying to find ways to speed up the software development process, but at the same time remembering that high quality is essential to building software that stands the test of time.
I have experience leading and architecting large Agile software projects and coordinating all aspects of a project's lifecycle. Whether you're looking for technical expertise or someone to lead all aspects of an Agile project, I have proven experience from multiple projects in different environments that can help make your project a success.
Every team and every situation is different, and I believe that processes and tools should be applied with common sense. I've spent the last 10+ years working on projects using Agile and Lean concepts in many different environments, both in leadership roles and as a practitioner doing the work. I can help you develop a process that works best in your organization, not just apply a prescriptive process.
Have any questions? Contact me for more information.
Ditching the Office - How an everyday corporate development team turned into a remote working team
From Stir Trek 2018
From Stir Trek 2017, cbus.js 2017
Iteration Management - Your Key to Predictable Delivery
From Stir Trek 2016 and QA or the Highway 2015
From CodeMash 2016, QA or the Highway 2014, Stir Trek 2012
The Business of You: 10 Steps For Running Your Career Like a Business
From CodeMash 2015, Stir Trek 2014, CONDG 2012
From Stir Trek 2013, DogFoodCon 2013
(presented with Brandon Childers, Chris Hoover, Laurel Odronic, and Lan Bloch from IGS Energy) from Path to Agility 2012
From CodeMash 2012 and 2013
(presented with Paul Bahler and Kevin Chivington from IGS Energy)
From CodeMash 2011
An idea of how to make JavaScript testable, presented at Stir Trek 2011. The world of JavaScript frameworks has changed greatly since then, but I still agree with the concepts.
A description of how test-driven development works along with some hands-on examples.
From CodeMash 2010
From CodeMash 2010