A rule of thumb that I’ve coined since I did ACS workflow is Pind’s Rule of Five: Before trying to design a general solution to a problem, implement at least five different instances of it, different in as many aspects as possible. Only then will you know what the right generalization is.
It’s going to take longer than if you just dive in, but the result is going to be a lot better. Workflow would definitely have benefited from this strategy.
This is the strategy I’m currently pursuing by building a bug-tracker, that’s everything I want it to be. Then building a couple more workflow-centric apps that’s everything I want them to be. Then I can take a step back and ask myself: How can I best refactor these, so they’re all built on a shared workflow infrastructure?
That way you don’t lock yourself into a stiff system that won’t let you do something you’d like it to do. And you don’t create a generalized solution for something that it later turns out, you don’t actually want.
A crucial component is to let time pass and let the app prove itself with users before you accept your solution and start generalizing it.
4 responses so far ↓
1 Peter Marklund // May 21, 2002 at 03:09 PM
Lars, thanks for sharing this rule! It makes some bold claims about the difficult issue of software reuse. The idea of first developing different implementations centered around a common generic problem before attempting the generic solution sounds ambitous but resonates very well with my experience.
A more well known and closely related software development technique is the idea of starting simple and letting your software evolve into a sophisticated and generic solution. This idea is one of the most important underlying principles of Extreme Programming and the Agile Manifesto. My own experience strongly suggests that this is an efficient approach to software development.
Needless to say, no simple rule can ever tell us exactly how and when software should be generalized and reused. However, I think the main benefit of Pind's Rule of Five is that it highlights and helps us avoid a quite common pitfall in software development, namely that of up-front over-generalization (aka over-engineering).
2 Nathan Carter // May 28, 2002 at 11:06 PM
3 Mike Arnold // Sep 30, 2002 at 01:57 PM
The workflow package you built may not be a perfect fit for your bug tracker, but couldn't it be minimally modified to suit? You seem to have rejected everything you learned while building the workflow package and started back at step 1 of the Rule Of 5 to build a bug tracker.
How is your execution of the rule of 5 not like 'pulling a Mozilla'?
4 Lars Pind // Sep 30, 2002 at 03:57 PM
On the contrary. First, I didn't rewrite the workflow package, so this couldn't be a mozilla.
But more importantly, what I did was to realize that I did not know what user experience I wanted for an application like bug-tracker. So instead of trying to generalize something I didn't know yet, I focused on writing a bug-tracker that did what I wanted it to do.
Now that we have bug-tracker, and I have experience using it on a number of projects, I know that part of the requirements for a workflow package much better. There are still other parts that aren't totally clear, but at least some is known. So if I were to get time or funding to hack on workflow, I'd know where to start and what to do.
The other things is the time issue: I judged that not only did I not know with enough clarity what was wanted to build the right generalized solution, i.e. workflow, it would also take way too long time. I think the problems with workflow are pretty deep, in that it's very rigid and heavy-weight to work with. I know from experience that it's not something you change overnight, there's a lot of work needed. I spent about 8 months working on workflow. In contrast, bug-tracker has taken 3-4 weeks total.
So I still think I did the right thing :)
/Lars