This post from Ayende made my laugh this morning. Specifically this:

if you need a tool in order to effectively use a piece of software, then you are already in a losing position.

I’d tend to say the opposite: if you’re not taking advantage of tools, you’re leaking efficiency.

In comments, Ayende wrote:

I write applications in notepad + command line, I am weird, I know…

Ayende talks a lot about “pain”. I can’t imagine anything more painful than writing code in notepad. I did that as an undergraduate; C on Unix with XEmacs and a command line compiler (Ok, so it wasn’t exactly Notepad; XEmacs is a step up, but it still wasn’t what I’d consider to be a true IDE, at least not without a lot of tweaking and editing). Fortunately programming tools evolve, as do most programmers.

I can’t imagine the pain that I’d feel if I had to write .NET without the IDE and ReSharper, for instance. Actually, I can. A few weeks ago I downloaded the XNA framework because I wanted to do a bit of game programming. My home machine did not have a license for ReSharper and instantly I felt the pain of having to work without it. I missed its ability to intelligently inform me about missing references, or gray-out unnecessary code. That didn’t make it impossible to write code, it just made it uncomfortable. I lost efficiency as a result.

I don’t look at tools as a handicap; I see tools as a way to make us more efficient programmers. And in a world driven by rapidly changing business desires I think it behooves us to have the best tools possible so we can be as efficient as possible. Efficiency is our lifeblood. Most companies don’t have the capital to support the Blizzard tenet of, “We’ll release it when it’s done.”

If you look at just about everything else in life that involves creation you will see that the tools have evolved. For instance, we don’t build skyscrapers with the same tools we did 100 years ago. We don’t build cars with the same tools we did 50 years ago. Musicians don’t even create music with the same tools they did 20 years ago. The tools evolve based on a singular purpose: to make the person more efficient at doing the job.

I find it particularly ironic that Ayende advocates building tools to take away pain points, but criticizes P&P for doing exactly the same thing. Then he says he writes in notepad + command line, which I can’t imagine anything being more painful. It seems like a real double standard.

At any rate, Ayende’s claim (that you need tools to use CAB) is wrong and fortunately Glenn Block corrected him in the comments. You don’t need SCSF to use CAB. In fact, for the first year of development, our shop didn’t use the SCSF. I built the first CAB application at work with just the API and some documentation. The bulk of the value for the SCSF comes with initial application creation. We later moved to the SCSF for one reason: so we could right click and generate the three class files for MVP. It only saves a few minutes of typing, but every edge we can get in development is worth it, in our eyes.

Efficiency is our lifeblood, after all.

5 Comments

  1. Bil Simser says:

    100% agree. I have a real problem with Oren attitude towards tools here. It’s all fine he wants to be the uber-geek and show he can build websites and applications in a single bound using Notepad and the command line. All the power to him. If he’s that much more efficient then great too. Hell, back when HTML editors sucked I wrote websites (ASP and ASP.NET) with notepad. However I’ve got past that and the tools have got better. These days I fly through code with Visual Studio and Resharper and it’s a good thing. I had the same issue with XNA as I was doing a Code Camp presentation and kept hitting my ReSharper keystrokes with all kinds of silly things going off (and most things not doing what they were supposed to). I’m all about efficiency, but I don’t believe you throw out tools because they don’t fit in a perfect world of notepad and DOS prompts. There certainly is a mastery in using basic tools, the raw CLR, etc. in buliding software but like any evoluation of an art, you use what makes you efficient and happy. If Oren likes his tools good stuff, but for me (and most others) I’m much happier with the new goodness.

  2. Casey says:

    Tools that make life easier are one thing – tools that are required to do things are another entirely.

    Using CAB is painful, using it with SCSF is somewhat more painful (in my experience). Both are significantly more bloated than they need to be for most scenarios.

    But that is the reality of software, the more specific you make it, the leaner it will become. The more generic you need to make it, the more it will bloat and become less performant.

    MS *have* to make their blocks highly generic as they are intended to be used in many different scenarios. And that is both their weakness and strength.

    But using SCSF as a retort to the argument that Ayende made (that CAB was overly complex and unweildy) was a mistake.

  3. Efficiency vs. Effectiveness, the CAB debate continues - Fear and Loathing says:

    [...] Efficiency vs. Effectiveness, the CAB debate continues There’s been two great posts on the CAB debate recently that were interesting. Jeremy Miller had an excellent post over the brouhaha, citing that he really isn’t going to be building a better CAB but supports the new project we recently launched, SCSFContrib. I think Jeremy’s excellent “Roll your own CAB” series is good, but you need to take it in context and not look at it as “how to replace CAB” but rather “how to learn what it takes to build CAB”. Chris Holmes posted a response called Tools Are Not Evil from Oren’s blog entry about CAB and EJB (in response to Glenn Block’s enty, yeah you really do need a roadmap to follow this series of blog posts). Oren’s response to Chris Holmes post got me to write this entry. In it he made a statement that bugged me: “you require SCSF to be effective with CAB” Since this morning, it looks like he might have updated the entry saying he stands corrected on that statement but I wanted to highlight the difference between being efficient with a tool, and being effective with the technology the tool is supporting. Long before SCSF appeared, I was groking CAB as I wanted to see if it was useful for my application or not and what it was all about. That took some time (as any new API does) and there were some concepts that were alien but after some pain and suffering I got through it. Then SCSF came along and it enabled me to be more efficient with CAB in that I no longer had to write my own controller, or implement an MVP pattern myself. This could be done by running a single recipe. Event the entire solution could be started for me with a short wizard, saving me a few hours I would have taken otherwise. Did it create things I don’t need? Probably. There are a lot of services there that I simply don’t use however I’m not stoked about it and ignore them (sometimes just deleteting them from the project afterwards). The point is that SCSF made me more efficient in how I could leveage CAB, just like ReSharper makes me a more efficient developer when I do refactorings. Does it teach me why I need to extract an interface from a class? No, but it does it in less time than it would take manually. When I mentor people on refactoring, I teach them why we do the refactoring  (using the old school manual approach, going step by step much like how the refactorings are documented in Martin Fowlers book). We talk about why we do it and what we’re doing each step of the way. After doing a few this way, they’re comfortable with what they’re doing then we yank out ReSharper and accomplish 10 minutes of coding in 10 seconds and a few keystrokes. Had the person not known why they’re doing the refactoring (and what it is) just right-clicking and selecting Refactor from the menu would mean nothing. ReSharper (and other tools) make me a more efficient developer, but you still need to know the what and why behind the scenes in order to use the tools. I compare it to race car driving. You can give someone the best car on the planet, but if they just floor it they’ll burn the engine out and any good driver worth his salt in any vehicle could drive circles around you. Same as development. I can code circles around guys that use wizards when they don’t know what the wizard produces or why. Knowing what is happening behind the scenes and the reason behind it, makes using tools like ReSharper that much more value-added. SCSF does for CAB what ReSharper does for C# in my world and I’ll take anyone that knows what they’re doing over guys with a big toolbox and no clue why they’re using them anyday.   Published Tuesday, May 29, 2007 7:24 AM by bsimser Filed under: General Software Development, CAB, .NET [...]

  4. Fear and Loathing says:

    Reusability vs. RYO…

    Every so often, a topic brushes by my RSS feeds that I have to jump into and comment on. The latest foray…

  5. My Software Blogs » Blog Archive » By Bil Simser - Efficiency vs. Effectiveness, the CAB debate continues says:

    [...] There’s been two great posts on the CAB debate recently that were interesting   [...]