Jeffrey Palermo (.com)

Sponsors

The Lounge

News

Recent Posts

Syndication

Tags

View more

Archives

Advertisement

Jeffrey Palermo (.com) » Who is to say that my knife is too sharp for my own good?
Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at imagehelp@codebetter.com
Who is to say that my knife is too sharp for my own good?

At DevTeach this past week, I had some great conversations, but one in particular is the conversation that many people have had:  about using sharp tools.  A common thought we come across is that a vendor or someone in management decides that the software team should be restricted in some way for their own good.  If this measure isn't taken, the software team could hurt themselves or the software could come out wrong.  Some of the analogies used are:

  • Running with scissors
  • Unsafe tools
  • If given a sharp knife, you might cut yourself.

These can be applied to many environments.  For instance, an argument against dynamic languages is that without compile-time checking, errors won't be found until runtime.  If developers are allowed to use dynamic languages for _real_ projects, then the software would fail because we don't know if it works until we run it.  (I won't bother replying to common arguments, but I invite readers to give their reply in the comments).

Unsafe tools could be IDE features, frameworks, libraries, or even permitted architectures.  For instance, if we use 3rd party libraries or frameworks, developers might hurt themselves.  Better stick to what comes from Microsoft.

Then, like children, I've heard that developers might cut themselves if given a sharp knife.

I credit 100% of the dysfunction of these thoughts to managers who allow or encourage these thoughts in their organizations.  Being a software manager myself, I know that I'm paying quite a bit for good developers.  I'm not paying for children, so I'm certainly not going to give them safety scissors, blunted markers or non-toxic playdough.  Developers should be adults, not children.  By the way, if you encounter developers who aren't professional adults, then HR functions should step in.  I want to give my developers the best, sharpest tools possible.  They might hurt themselves or the company?  There are other ways to manage that risk other than giving developers safety scissors.

I was reminded of these conversations by a blog post by Oren Eini, with whom I spoke about this issue at DevTeach.  Oren came up with the following logo, which enumerates that one of the facets of the spirit of Alt.Net is that developers are professionals, and if there is a need to run with Scissors amids flying bullets, then they are capable of making that decision.

Chad Myers quickly condensed it down to the badge that I've added to my blog:

Posted Sun, Dec 2 2007 4:47 PM by Jeffrey Palermo

[Advertisement]

Comments

Sandor Davidhazi wrote re: Who is to say that my knife is too sharp for my own good?
on Sun, Dec 2 2007 7:11 PM

You wouldn't give your developers the nuclear bomb, would you?

Jeffrey Palermo wrote re: Who is to say that my knife is too sharp for my own good?
on Sun, Dec 2 2007 7:17 PM

@Sandor,

I'm not sure what the nature of your question is, but we're talking about sharp development tools here.  Can you rephrase?  I did serve in a war with the U.S. Army, but I'm 100% civilian now, so I'll stick to those terms.

Avner Kashtan wrote re: Who is to say that my knife is too sharp for my own good?
on Mon, Dec 3 2007 5:22 AM

No, developers aren't children. But they aren't infallible, either. We all know that software has, and will always have bugs. There are tools we can use to mitigate them and eliminate much of their risk. Some of these tools are methodological - code reviews, unit testing and so forth. Some are technological - a managed environment frees us of many memory management bugs. I, as a developer, often want to limit my freedom in order to get safer, easier-to-use tools.

Remember also that tool vendors have a specific goal - to sell more copies of their tool. That's perfectly reasonable.

If you sell a toolkit that is harder for the developer to use, or can result in more bugs if the developer isn't careful with every step (and I've used plenty of 3rd party components that I had to massage delicately to make work) then people won't blame their bugs on their own carelessness, but on YOUR component.

When I buy a 3rd-party component, I often want it to function like a home appliance - plug it in, start working. Maybe read the user manual if things are unclear. No more.

Jimmy Bogard wrote re: Who is to say that my knife is too sharp for my own good?
on Mon, Dec 3 2007 12:15 PM

@Avner

I think you have to distinguish between components and frameworks.  Taking the carpenter analogy, frameworks are like the carpenter's woodworking tools.  General and multi purpose, they can build wood masterpieces.  Sometimes all you need is a saw.  Sometimes you need a table router, and the carpenter has the knowledge and experience to know when to use what.

Limiting the carpenter to a hammer and a saw will produce clunky, unusable furniture.  The carpenter will likely quit his job and move into carpent-ecture, where he can wave his hands about saws and sanders.

Components on the other hand, aren't meant to be a foundation for building.  They're more like a carpenter's final product, like a chair.  You can use a chair to sit on, stand on, but you don't need instructions to use it.  You can build a table out of chairs, but it's not something anyone will eat on.

Jeffrey Palermo wrote re: Who is to say that my knife is too sharp for my own good?
on Mon, Dec 3 2007 6:49 PM

@Avner,

I don't think I claimed that developers are infallible, so I agree with you on that.  I certainly did not advocate throwing away risk management tools that reduce bugs, like automated testing, continuous integration and frequent deployments and integration testing.

The remainder of your points are a good extension to the conversation, and represent tools that do not limit developers but rather are enablers that increase productivity.

Joe Brinkman wrote re: Who is to say that my knife is too sharp for my own good?
on Mon, Dec 3 2007 6:56 PM

It is amazing how this very argument is used to bash the WebForms framework.  People argue that we need MVC because WebForms leads developers to build crappy, untestable apps.  My counter argument is that it doesn't matter what framework I give developers, some devs will build software masterpieces and some will build unuseable apps.  The issue is not the framework but the developers.  I don't believe in limiting developers but I do think that sometimes it is ok to add airbags... just give me a way to turn them off if I need to.

Jeffrey Palermo wrote re: Who is to say that my knife is too sharp for my own good?
on Mon, Dec 3 2007 7:08 PM

@Joe,

I'm not sure about WebForms being equated to a sharp tool.  I'd equate it to a dull saw.  If you push hard enough, you'll get it to work.

People have build great application with WebForms despite the code-behind model being untestable and awkward..

You are correct with you point that some developers will create unmaintainable applications regardless of the framework, but I'd submit that specifically the MVC framework isn't targeted at those folks.  It's targeted at the folks who aren't happy with the blunt tool that is WebForms.  

Good developers will find a way to sharpen even blunt tools.

Haacked wrote re: Who is to say that my knife is too sharp for my own good?
on Tue, Dec 4 2007 3:42 AM

The irony is that I've heard from many in the TDD community and ostensibly in the ALT.NET community the same arguments about tools being too sharp when describing TypeMock. They say that TypeMock is a nuclear option and that unlike other mock frameworks, it allows you the luxury to be lazy about the design of code since you can mock anything. You don't need to write testable code.

The reason I say this is I've made that argument myself! But now I need to rethink that. :)

Jeffrey Palermo wrote re: Who is to say that my knife is too sharp for my own good?
on Tue, Dec 4 2007 8:29 AM

@Haacked,

I certainly won't speak for everyone, but I haven't described TypeMock as "too sharp", and I won't.  I've spoken to many people who find it very useful.  I don't use the tool, but that alone is not a condemnation of it.  

I am struggling to grasp where the irony lies, however.

Carlton wrote re: Who is to say that my knife is too sharp for my own good?
on Tue, Dec 4 2007 11:56 AM

I tend to eschew sharp tools for inexperienced developers.  I think they need to prove a mastery of the basics - TDD, CI, timeboxing, incremental development, etc., etc. - before allowing them  to play with latest "shiny shit".  You are not going to stop them, but at least you can slow it down until the technology has had a chance to coalesce.

Jeffrey Palermo wrote re: Who is to say that my knife is too sharp for my own good?
on Tue, Dec 4 2007 12:08 PM

@Carlton,

I think custom woodworking is a great parallel to development for the purposes of this post.  In custom woodworking, you work with sharp tools, but to your point, you wouldn't give these to a novice without proper training.  You would have them work with an experienced woodworker until they were capable of being effective on their own.

I see the same dynamic in software.  Let me extend your comment with my opinion that regardless of the tools involved, I wouldn't turn a novice loose on a client's codebase alone.  They would have to have the proper training regardless of tools.  Giving a developer dull tools in lieu of proper training is no substitute.  

I think I would lean more toward having an apprentice developer pair with a master developer using the tools of choice rather than modify the tool set and have the apprentice (attempt to) work alone.

Carlton, your point about mastering the basics is a very good one.  Without this mastery, tools are irrelevant.

Scruffy-Looking Cat Herder wrote Dependency Injection Objection
on Mon, Dec 10 2007 7:46 PM

Dependency Injection Objection

Ayende @ Rahien wrote Dogmatic? Who, me?
on Tue, Dec 11 2007 2:54 PM

Dogmatic? Who, me?

jsmith wrote re: Who is to say that my knife is too sharp for my own good?
on Thu, Dec 13 2007 2:40 AM

It's simply not productive to limit all developers at all times simply because some of us make mistakes some of the time. Besides, you can't learn if you don't make mistakes. In a testing - fail fast oriented work context, the tools should be sharp. Lhotka's Csla framework drives me nuts. Everything is bolted down to protect me from myself. You have to stand on your head to do test-first development. That's actually pretty funny -- a "safe" application framework that discourages tdd.

Fregas wrote re: Who is to say that my knife is too sharp for my own good?
on Thu, Dec 20 2007 1:47 PM

I think this arguement over "sharp tools" can be narrowed down to two questions:

1) Does the tool, framework, component, etc. make me more productive now?

2) Does it allow me to write maintainable code so that i'm still productive in the future?

People object to dynamic languages because the fear is that they give you #1, at the expense of #2.  People object to TDD for the opposite reason (at least initially.)    The problem so often is that a given tool gives you one option at the expense of the other.  However, long-term, going with option #2 seems to be better because as we all know, applications change and there is more expense in maintaining them than in building the first version.  

Some people feel that they can get the extra productivity of Ruby and other dynamic languages by offsetting the risks using TDD to catch errors before runtime.  Others feel that they can avoid the need to use TDD by using a statically typed, compiled language such as java or C# because they get *some* error checking built in.  

Justin myJustin = new Justin( Expriences.Current ); wrote "Prefactoring", By Ken Pugh, O'rielly (2005)
on Wed, Dec 26 2007 9:34 AM

I'm reading " Prefactoring ", By Ken Pugh (O'rielly 2005) and I'm jotting down

Jacob Proffitt wrote Dependency Injection Objection
on Wed, Jan 9 2008 4:43 PM

I’ve been putting off a follow-up on Dependency Injection for a couple of months now. The amount of heat

TechMount » Archive » Daily Friction #308 wrote TechMount » Archive » Daily Friction #308
on Tue, Feb 26 2008 11:16 AM

Pingback from  TechMount  » Archive   » Daily Friction #308