Jeffrey Palermo (.com)

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.

@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.

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.

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. :)

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.

Dependency Injection Objection

Dogmatic? Who, me?

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.

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.  

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

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

Pingback from  TechMount  » Archive   » Daily Friction #308