Pulling others up
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.
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.
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.
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.
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
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!
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.
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,
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.