Educate Developers Instead Of Protecting Them

21 commentsWritten on April 15th, 2009 by
Categories: Opinions

A lot of companies have a couple of technical people who are responsible for laying down some technical guidelines, rules, or even reusable libraries or small (or large) frameworks. The idea is that all the developers within the company (or department) need to follow the same rules, use the same libraries, and pretty much write similar code compared to everyone else. I'm not going to get into the benefits/drawbacks of this, but there is one important aspect of this approach that i've seen in a few places which i'd like to comment on.

What you often see in this kind of situation is that the people who make up the rules (let's call them the 'technical leads' for the purpose of this post) often try to protect less-skilled developers from making mistakes or even assume that less-skilled developers won't be able to comprehend certain technical principles/aspects/patterns/approaches. Btw, i don't mean the term less-skilled developers in a derogatory way... but that is often how technical leads in places like these think of 'application developers', especially those who still have a lot to learn. This often leads to guidelines, or even API's which are heavily influenced by the perceived lack of skills/insight/knowledge of the less-skilled developers.

I'm sure you all have countless examples of situations where technical leads impose restrictions or guidelines based purely on their lack of faith in less-skilled developers. Hell, just browse through Microsoft's Framework Design Guidelines and you'll encounter quite a few more examples of how some of the .NET Framework's technical leads made choices or still recommend certain things based largely on having to deal with less-skilled developers who might not have the required skills to do everything the proper way. (Side note: i do like the FDG book and find it quite helpful in many situations, though the parts where they talk about less-skilled developers really do annoy me).

In the large majority of cases, trying to protect developers from themselves is just not worth it. For starters, hiding things from developers often requires more effort in the long run than simply trying to educate your developers as to how they should properly do their job. Sure, you can wrap anything that you deem as potentially easy-to-misuse, but you will need to think about alternative approaches whenever you have to deal with a situation in an application that falls outside of the boundaries you had in mind when you wrote your wrapper. And this is where it usually gets very messy, very quickly.

On the other hand, you could have invested some amount of effort into guiding and teaching those developers who you might consider as less-skilled. If you're going to hide things from less-skilled developers, how can you possibly hope that these developers will one day require less hand-holding and protection from themselves? The only way these developers are going to reach the level you'd like them to be on, is if somebody is going to help them get to that level. It might not always be easy, but it's usually far more effective in the long run than simply having to deal with their (perceived) lack of skill forever and ever.

Another huge downside to protecting developers from themselves is that it easily puts off the strong developers. Just imagine that you join one of these companies/departments where they do this. You know the ins and outs of certain libraries or frameworks, yet you are being restricted because the powers that be don't want your less-skilled coworkers to screw up. How likely are you to stick around for a long time in a place like this? How motivated could you be, knowing that you'll often be restricted on a technical level?

Basically, there are 2 huge downsides to this. The first is obviously that your less-skilled developers are never going to improve. You will be stuck with their perceived inabilities forever. The second is that it will either drive your competent developers to look for a better job, or if they stick around they might tune out, which could lead to a whole other host of problems. All of this can easily be avoided by simply showing your willingness to help educate your developers. They will benefit from it, and as a result, so will you.

« NHibernate’s Future Queries And Their Fallback BehaviorPut Performance Concerns Into Perspective »

This entry was posted on Wednesday, April 15th, 2009 at 22:04 and is filed under Opinions. You can subscribe to any comments to this entry via RSS 2.0. You can leave a response, or trackback from your own site.

  • pho

    So do you have a practical example to back up all this? I’d like to see a piece of code what these technical leads deem as “out of the lesser developers’ league”

    Still,
    if you can abstract a certain reusable functionality to a library that can be reused by other people that need it in your company, why shouldn’t you?
    As a matter of fact, i think we do it that way… Or am i totally missing the point here?

  • http://davybrion.com Davy Brion

    yeah i do think you missed the point :p

    i’m not saying that you shouldn’t offer reusable libraries… i’m saying that you shouldn’t _hide_ things that you deem as too powerful or potentially risky behind these reusable libraries

    as for practical examples… one thing that i’ve seen way too often is that people offer datalayers that are easy when you’re doing simple stuff, but don’t really offer a clean way to do more powerful things. I once tried to introduce NHibernate at a client, and their initial response was “NHibernate is powerful and can be misused very easily… we should wrap it and make sure people can’t access it directly”. It would’ve worked great for simple stuff, and it would’ve gotten very messy once you need something beyond the simple stuff. Codegen’d DAL’s often show the same problem IMO.

    Another example was also at a client where the Microsoft consultants basically wanted to hide exception handling from application developers because “they don’t understand it anyway”. Which led to a shitload of code where people were constantly checking return values, which was obviously a lot more error prone than typical .NET exception handling code would’ve been.

    Another example was a ASP.NET Webforms based state machine which did all of the navigation and state management that you typically have to do on your own. The developers were writing pages and use cases with it, but they no longer thought about it… which lead to horrible abuse of the state management that was provided because the developers weren’t properly educated on how to deal with state management in a web application.

    ViewState in ASP.NET is another nice example… it’s an easy to use abstraction so developers can do some form of state management in an easy manner without using server memory for it. Until people dump everything in it because they don’t know any better.

    There are tons of examples available…

  • Jonathan Kaufman

    Microsoft consultants basically wanted to hide exception handling from application developers because “they don’t understand it anyway”.

    Wow Davy, I am kind of withthe other poster. I have never seen this behavior in people before. I agree with idea of your post but never ran into the situation.

  • http://invinciblezombiecow.wordpress.com/ RCE

    @PHO: it’s all nice & dandy until you hear that you should not apply certain techiques because you should program to the ‘lowest common denominator’ and ‘some people might not understand what is going on’.

  • pho

    maybe the other option would be hiding and abstracting the difficult things while still making sure every developer working on it understands

    i’m sure in all of the examples you mentioned, the originators of the ideas had the best intentions in mind. the fact it got screwed up (e.g. that state machine that was horribly misused) is most probably just the result of bad follow-up. which you will need to do anyway, whether you hide all the difficult stuff or not. just make sure that if you do, everyone GETS why it’s done like that
    i don’t think guidelines/principles of any kind are bad for a team working on a project (as long as it makes sense and you’re not overcomplicating…)

    @rce: yeah that’s pretty retarded :-)

  • http://davybrion.com Davy Brion

    I have no idea where you got that i believe guidelines/principles are bad… _bad_ guidelines/principles are bad, especially when they are put in place to deal with the ‘lowest common denominator’ as RCE states… that’s how it often is in big companies, and as you say, it is retarted. That’s pretty much what the post is about.

  • http://www.filip.duyck.org efdee

    I can throw in some experience I had at a previous client – a rather large company with 50-100 .NET developers and a central ‘competence center’. Developers were forced to use certain frameworks, in order to standardize common aspects of the application such as DAL access.

    Sadly, the framework was given in closed-source form for exactly the kind of protective reasons I think Davy is talking about. Whether I liked it or not, this worked relatively well in the beginning. Problems were quickly dealt with and guidance was always available – until after a few months things got a bit busier. We ran into a problem (actually, more of a missing feature) but were unable to get help because everyone at the competence center was busy helping out on other projects. After losing plenty of time trying to go through the ‘correct’ channels, we used reflector to decompile the framework, learned how it works, made the necessary modifications and went on using that version instead. I left before the project was finished, so I’m not sure if the modifications ever made it back into the official version.

    I’m not saying the framework was a bad idea, but if they had chosen to given out the source code to developers instead of ‘protecting’ them from what was going on, not only would we have saved alot of time, but it might have educated those few developers that would have had the interest in looking at the source code while using the framework.

  • http://yoot.be Steve Degosserie

    The main problem, IMHO, is that some so-called senior developers and / or architects that have a high position in companies, and that are those who define the guidelines & best practices, usually think they know how to write good framework / library … but they just don’t.
    Writing highly re-usable framework / library shielding less experienced developers from mistakes while at the same time leaving a door open for more advanced ones is just hard. Really hard.
    We’ll all seen senior developers that know a lot of technologies, the latest cool stuff but when you look at their code, they don’t even seem to apply the basic rules of encapsulation.
    To repeat it again, Framework / Class Library / API Design is a DIFFICULT TASK.

    And I think that’s the point Davy wants to emphasize (correct me if I’m wrong) … teaching less experienced developers is important, but from a business point of view, when you start to have several development teams that needs to coordinate and all apply the same guidelines & best practices, it makes total sense aim for maximum reusability & higher abstraction levels.

    Otherwise, we should all quit our fancy UIs and go back to the command line ;o) lol

  • http://yoot.be Steve Degosserie

    To quote A. Einstein, it’s all about making everything as simple as possible, but not simpler. ;o)

  • http://codinghillbilly.com Kyle Baley

    There’s more to it than abstracting “complicated” libraries like NHibernate. I’m in a situation where unit tests and mocking are taboo because the maintenance team can’t handle it (all testing is done with integration tests). Even things like var and LINQ have raised hackles. Still new to this project so am trying to find the balance between introducing too much and being productive but it’s a moving target from one client to the next.

  • Joe Young

    I am a bit confused about the meaning of protecting? Is it just hiding things from other developers and creating guidelines? How does opinionated code fit in to this, or does it?

    I have been moving to more and more to having a highly opinionated api. This will basically setup a mechanism where there is one and only one way to do something. Am I protecting developers and myself by creating an opinionated api?

  • http://davybrion.com Davy Brion

    @Joe

    with protecting, i mean it’s more about hiding power that could potentially be used wrongly. Instead of fearing that developers will make mistakes, and thus hiding power from them, i think it’s better to invest time into educating them so they are less likely to make the mistake in the first place

    opinionated api’s aren’t really an example of that, though they certainly can be. Having one and only one way of doing something isn’t wrong, unless that way isn’t sufficient once you get beyond the trivial stuff.

  • Ashish T

    This is a nice post. Thanks for putting it out.

    In my group, similar things are happening. But, the difference is, there are some people who do not want to learn the new way of doing things. I am currently working on creating an application framework that works similar to plug-ins. There are many interfaces and base classes to learn and use. I am using dependency injection (using spring.net) and nhibernate for DAL. People in my group, who will be using those, want me to simplify them further because they think they will not be able to grasp and understand how to whole thing fits together. I have been trying to educate them by sitting with each developer and explaining what is what.

    Looks like in this case, I will need to hide certain things from them.
    Any suggestions on what I should do?

  • http://davybrion.com Davy Brion

    Well, i have no idea what your interfaces and base classes are like, or what they are trying to accomplish, but i would try to take an objective look at the complexity that the developers are currently experiencing when using those custom classes.

    If they aren’t introducing needless complexity, and the devs really don’t want to learn, i’d suggest writing some docs about it. It might be boring, but that way you’d only have to waste time on explaining it once. And for those devs that do care, you can still go through it with them

    But i’d really try to look at the root cause as to why they don’t want to learn (or appear that they don’t want to learn)… there might be a bigger problem lurking there

  • http://www.anzpaa.org.au Bruce

    I have usually found the abstraction is not because of technical reasons but due to security or other business issues. This does make it difficult for developers to do “interesting” stuff. It is probably not possible to overcome this type of control.

    When contracting I have often found that doing advanced techniques gets the criticism from “in house” developers as they do not want to have to code outside there box of knowledge. This is the type of attitude that is worse than guidelines or libraries as it usually provides a negative impact on the dev’s and the end users.

  • http://programmergrrl.com Amy Thorne

    In my experience, many companies that do this don’t want to invest in educating their developers. Instead, they invest in rules and frameworks and use developers as interchangeable parts.

    I’m not saying it’s a good idea. I completely agree with your point. I’m just saying that the people who decide to protect the developers might not care about the downsides you point out, or might have already concluded that it’s cheaper to work around them than to fix them.

  • Pingback: Educate Developers Instead Of Protecting Them | The Inquisitive Coder – Davy Brion’s Blog « Jay Nathan

  • Dalibor

    This – http://martinfowler.com/bliki/ServiceCustodian.html – looks like a possible solution to the problem that you have pointed out.

  • Justin

    This is the reason why I pair program with the junior developer on my team when I create an API for our systems. We’ll have an easy to use API at the end but he can watch it being built and help to build it himself. This will reinforce the concepts of TDD and whatever I am building to him, and usually I learn a little something in the process.

  • Alan McBee

    I agree with your ideals, but my practical side has some objections. You and I (and presumably most of the commenters here) are clearly motivated to seek understanding so that we may hone our craftsmanship. For this group, I agree that education is the better approach, since we will be reluctant to claim mastery until we feel certain. In contrast, my experience suggests that many developers are motivated in two different ways.
     
    First, some are motivated to demonstrate their prowess. These developers only seek enough understanding that they can stand out from other developers through claiming proficiency with intimidating technologies by having used (abused?) them. I’ve had the misfortune more than once of having to undo the disaster that some previously-heralded developer had created. (Perhaps I’ve made my own, but let’s not discuss that, shall we?) It was apparent that these developers had a poor understanding of some key technologies or patterns, but had convinced others that they could properly apply multithreading, or deep-inheritance design, or caching. Unfortunately, we have no simple objective test to reveal the unintended harm these well-meaning developers create.
     
    Second, some, and I dare say most, are motivated to just get the damn thing working and move on to something else. They learn new technologies or techniques only when they are required to by the task before them, and then, only as much as it takes to pass whatever quality checks are actually performed. Although I can never see myself following this approach, I have to reckon with the high probability that a great deal of programming is accomplished by this group.
     
    For these two groups, education is not the answer. For the first group, once they have barely grasped the shiny hammer of a brand-new technology, they need to nail somethine with it. Then, once that nail has taken hold, they’re ready for a new hammer. The fundamentals of good programming are lost on this group. It is, after all, challenging to assert mastery of basic skills on a résumé and have it stand out. For the second group, education is perceived as a necessary evil; it steals time from productivity.
     
    Tempting though it might be to regard both of these groups as merely needing an attitude adjustment, we know that changing other peoples’ attitudes is enormously difficult. From a pragmatic standpoint, it’s probably not worth the cost. Alternate approaches are needed. And from that position, I think it might be appropriate to protect other developers from making mistakes. Naturally, this will irritate you, as it would irritate me and many other good developers, since we would probably know or would be willing to learn better techniques.
     
    The point I’m getting to is that I think your concept of “less-skilled developers” might be a misnomer. “Differently-skilled” might be better, even if it does seem a tad bit politically correct. We might want to believe that most “less-skilled” developers would see themselves as such and would desire to make themselves into “better-skilled” developers. But I think what’s really true is that any developer who did consider themselves to be a “less-skilled developer in pursuit of being a better-skilled developer” is really just a better-skilled developer in-the-making. The other classes of developers (the show-offs and the nine-to-fivers) have no desire to make themselves better at the craft of fine software development.
     
    So, for us fine craft workers of software, I regard the principle of protecting-developers-from-themselves to be distasteful but necessary. And given my propensity to want to learn all technologies, all techniques, all patterns… maybe it’s a good thing, since sometimes I have to actually produce something long before I feel like I fully “get it.”

  • Pingback: » A Smarter Infrastructure: Automatically filtering an EF 4.1 DbSet Clarity Blogs

Meta

Recent Posts

Categories