Safety versus Power

Dean Wampler wrote a post called Protecting Developers from Powerful Languages that reminded me of a running conversation I have with one of my client developers on "pointy tools versus idiot proof code." 

It all started when I asked him to open up some constructors on the pseudo domain classes so we could more easily write unit tests involving those objects.  He had a concern that developers would use these "testing" constructors and the persistence layer would then crap out.  When he asked me how we could make idiot proof code my answer was the hiring process.  Some other answers might be mentoring, knowledge sharing, and streamlining your API's (!).  At the end of the day, I don't think there is any possible way to succeed if you can't trust your developers.

A related concern that I've wrestled with all of my career as a technical lead is whether or not you limit the sophistication of your development approaches to the existing skillset of your team.  Sometimes hitting your teamate's ceiling might just be a sign that your design ideas are unnecessarily complex and unworkable.  Other times you should plow ahead with the knowledge that you'll need to invest in your team members.  Sometimes you just punt because you simply cannot succeed with a design that your team as a whole can't grok.  If you want the real answer you gotta go find someone wiser than me.

 

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • paweł paul

    Nice posts,… you need informations about I feel really happy to have seen your webpage and look forward to so many more entertaining times reading here great job! forex broker rating

  • http://hammett.castleproject.org hammett

    Jeremy, there seems to be some wounds about your former employee (which some years ago was a well respected company, but for some reason lost valuable talents). Why dont you share with us what happened? I’m specially interested as my company is an agile practitioner, and I love to know what _not_ to do in advance.

  • JBarbatos

    It’s interesting you hear someone say that they are sticking with smaller companies, I used to work for a smaller company that had the same problems. Most signs point to the director of applications not having a clue (an old VB4 developer that never grew up technology wise). I have since moved to a bigger company (3 IT to 30ish) and things still seem to be about the same. I have since gotten our group (3 programmers) to try DDD, TDD and I just set up Cruise Control for CI. The downside is since I am new to all these as well, I question if everything I am doing is right. I wish we had someone else with these interests just to have someone to bounce ideas off of, or a different point of view on how to implement these.

    As for the hiring side of things, we just hired our 3rd developer who is technically weak. The problem being she is used to having business analyst telling her what/how to things, and no longer has that luxury. I used to work with her and knew this area would be one of her weaknesses, yet something we still need, yet I was overruled. Maybe she will catch on to some of the simplier concepts quickly, I just have a hard time teaching something I am still learning.

  • http://www.agilejoe.com/ AgileJoe

    Jeremy,

    As far as limiting the sophistication of your development approaches to your teams skill set. I am a firm believer in growing people. (Now that doesn’t translate into driving new technology down people’s neck but slowly introducing new concepts in small digestible chunks) Everyone that has introduced agile practices should be able to attest to that statement. Remember when the concepts of TDD and paired programming where first introduced. Remember all the frustration and unwillingness to take on these practices. But slowly everyone came on board and realized the benefits but they did it corporately as one team. I have found that as long as you introduce new concepts and practices into your development group as opportunistic possibility. Organically they will self organize around the concept and determine as whole if the idea or technology is sustainable. At that point through the spiking and peer pressure they will either excel or ask for additional training. The complexity of the language or the suppleness of the architecture seems to be somewhat trivial as teams self organize. At the same time these opportunistic possibilities will sometimes lead to developer turnover but 9 time out of 10 the developer that does leave has had problems in the past gelling with the team.

    I agree that working in the corporate sector has its tradeoff’s but for those (like my self who still work for the man); there are partnerships you can establish with HR. I use HR as an initial screening tool only then to invite the recruiters to take part in the development interview. After the development interview and an hour or so of QA from the recruiter grilling me on what OOP and TDD are, they eventually get it right and start to find qualified developers. Again partnerships are the key here. If you don’t you will find yourself muddling through hundreds of junior developers or old main frame developer’s resumes, that want to catch up to the 21st century.

    I know this is rather long winded but team development is something that I feel very passionate about. Teams complete projects not glory minded developers!

  • http://codebetter.com/blogs/jeremy.miller jmiller

    Steve, that’s why I’m only willing to work in small companies now, and I emphatically agree about the referrals.

  • http://stevenharman.net/ Steve Harman

    To your point about using the hiring process to ensure quality code… I couldn’t agree more!

    However, in my experience I’ve found that in large corporations the HR department often has predefined channels for funneling all prospective talent into your group. And getting a truly talented candidate via these official channels is pretty rare. They just don’t seem to attract the types of rock star developers that we all want. They seem to be a source of quantity, not quality.

    I suppose it’s obvious, but the best talent seems to come via referral… which makes total sense. I know I sure the hell wouldn’t refer someone I thought was sub-par… if I did, what would that say about me.