Jeffrey Palermo 10:47 pm on December 2, 2007

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:

Sandor Davidhazi 12:11 am on December 3, 2007

You wouldn’t give your developers the nuclear bomb, would you?
Jeffrey Palermo 12:17 am on December 3, 2007

@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 10:22 am on December 3, 2007

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 5:15 pm on December 3, 2007

@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 11:49 pm on December 3, 2007

@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 11:56 pm on December 3, 2007

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 12:08 am on December 4, 2007

@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 8:42 am on December 4, 2007

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 1:29 pm on December 4, 2007

@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 4:56 pm on December 4, 2007

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 5:08 pm on December 4, 2007

@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.
jsmith 7:40 am on December 13, 2007

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 6:47 pm on December 20, 2007

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.

Comments are closed.

Programming with Palermo

Jeffrey Palermo, Microsoft MVP, Author, Speaker, Clear Measure Chief Architect, Azure DevOps Expert

Who is to say that my knife is too sharp for my own good?

Related