Wednesday, March 09, 2005

Questioning the one true faith

A few months ago, I made the unfortunate decision to post a somewhat derisive entry on my blog about Fusebox and my personal, anecdotal experiences with it. Even then, I realized that my comments could be viewed as being overly critical of the framework. I tried to backpedal a bit and at least acknowledge some of the excellent discoveries and fine work that has gone into its development. It didn't receive much attention when I wrote it and I was content to let the post just fade into history.

I should have known better.

Andy Jarrett resurrected the subject when he spoke about his adventure building a small project that he felt didn't need the formality of the Fusebox framework. [thanks a lot Andy ;-) ] It sounded like he had a lot of fun with the project.

Over the past year or so, I've been exposed to 3 Fusebox development environments. One with a team of 5, one with 15 and one with 32. All three worked multiple projects simultaneously. NONE of them are contemplating a move to Fusebox 4 or Mach-II. Development environment inertia at its worst.

At the 5 member team organization, we were able to put together a second team and environment without Fusebox and watch the organization for almost 3 years. The second team had 6 developers move through it but never more than 3 at a time. The original 5 member team moved an additional 4 people through during the same period.

The smaller team more than kept up and in many cases surpassed the larger team in terms of speed of code generation, flexibility of design, responsiveness to changes, maintenance of existing code, etc.

The small team had a rocky start including a short dabble with cfobjects and some in-house framework attempts. After cfmx came out, the small team began to see gains in productivity. The large team performance was flat. This was most evident on an integration project between the two groups. The small team was always ahead of the large teams schedule on two ends of the same project. The small team's code had fewer bugs, required less rework and was easier to maintain.

Similar patterns were evident at the other two organizations.

Since my experience is purely anecdotal, it's quite possible that these are not typical results. Our small team almost always had somebody with previous oo experience in other languages, either java, c++ or c#. The large team was pure cf with a bit of asp. The smaller team also had been exposed to enterprise design/management tools and ideas like the RUP and had done lots of modeling with the UML.

Where the larger team was unwilling/unable to do anything but Fusebox 3, the smaller team chafed at the prospect of adopting it.

The organization that had 30 devs was completely stuck on cf5. They were unable to solve some technical driver issues and were unable to upgrade. I hope they have been able to work that out. Again, there was very little interest in even putting a pilot together in a lab environment.

The middle outfit is getting some really good mileage out of Fusebox 3. They have a very narrowly focused set of products and are delivering their products rapidly and consistently. They have been skilled/lucky enough to retain their original developers.

My guess is that this is what most Fusebox organizations are experiencing. However, there is some dissention in the ranks. There is some frustration with lack of interesting projects. They are a pretty forward thinking organization and yet they are not even evaluating Fusebox 4 or Mach-II.

I'm there building something that nobody else wanted to tackle (a mainframe/cobol integration). In the process, I've turned a few heads in terms of thinking about their software lifecycles. I'm not pushing anything on anybody, I'm just showing my work each week and explaining what's going on.

I don't have any empirical evidence one way or another regarding Fusebox. There probably isn't any. As an industry, we have enough trouble just trying to estimate project size. Measuring gains in productivity quantitatively is beyond most organization's capabilities.

So, was my original post completely off the mark? I don't think so. My experience leads me to believe that some of the benefits proposed by Fusebox are overhyped. I think I would rather have seasoned developers than a framework and inexperienced developers.

Was the original post an eloquent statement of position? Nope. Especially that line about using Fusebox in a shared environment. That one was a mystery to me when I first read it. Where I had intended to go with that was to discuss some of the challenges presented by multi-homed sites where you don't have access or control of the hosting environment.

Based on some of the comments I received, you would have thought I had said that the Pope was praying to the wrong Gods. Sheesh, relax a little bit. You'll live longer.

So, for the next six months or so, I'm not using Fusebox. I don't want to. You can't make me. Nyahh.

Unless of course you want to pay me large sums of money. At that point, all other religions become false.


  1. Just discovered this post while revisiting your old Fusebox post (after the "anti-framework / anti-OO" thread on my blog!)...

    The biggest differentiator between the two teams, IMO,, would have been the OO / UML / RUP experience. Pity that team were too arrogant to try Fusebox - it would have been really instructive to see how the two teams performed using the same framework (I think the difference in experience would have then shone through as the key to productivity). It's also very telling that they had a rocky start because they did not adopt a standard framework!

  2. Such are the limitations of managerial budgets.

    Funny, though, how you pity the arrogant OO team, when in fact, if there was any arrogance there, it was with the Fusebox team that were convinced they had discovered the only way to write software. If anything, the OO team was humbled by the task of learning fusebox. The OO team also felt that moving to pure procedural code was a bit of a step backward, but they were willing to do it. When OOcf became a tangible thing, they, I think reasonably, attempted to see how much of their prior experience could be used with it. I don't think an arrogant, "we're better than you", thought ever was expressed. It was more of an "Oh, crap. We don't know what the heck we're doing working in CF. Let's see how we can make it look as much like what we used to do" kind of attitude.

    I have to agree, that the team is pretty much always the biggest impact on a development project. It doesn't matter what technology you use, a stronger developer team will generally overcome most language shortcomings (provided that we are comparing roughly the same generation of technologies).

    Personally, I'd rather have a team working for me that takes a little more time getting out of the gate than consistantly coming up short at the finish line.