Pind's Rule of Five

Other
May 16, 2002
by Calvin Correli
2 min read

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.

Like

About Calvin Correli

I've spent the last 17 years learning, growing, healing, and discovering who I truly am, so that I'm now living every day aligned with my life's purpose.

Read more
Read next

Who's our role model

4 comments

Peter Marklund
 

insightful and novel! <p> 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. </p> <p> 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 <a href="http://www.extremeprogramming.org/">Extreme Programming</a> and the <a href="http://www.agilemanifesto.org/">Agile Manifesto</a>. My own experience strongly suggests that this is an efficient approach to software development. </p> <p> 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). </p>
Read more
Read less
Reply over 22 years ago
  Cancel
Nathan Carter
 

open source development methodology: "Apache-style" vs. "ArsDigita-style" I think I've seen the same rule quoted elsewhere as a rule of three, but the same truth applies. I've been lurking on several of the Jakarta and Apache XML user/dev lists lately, and I've been impressed by the sheer number of people from BIG companies with BIG requirements that are using and contributing to the development of different Apache "components" - for instance a number of big financial companies are using Apache FOP to generate PDF forms and reports, and obviously many folks are using Tomcat, etc.. The quality of the discussions and the truly "practical" nature of the problems discussed give many of the Apache projects a real test of generality (or "horizontalness") across a significant number of industries and "verticals" - they don't have to write a one-off five times before generalizing, but they discuss a number of different options, someone from each "vertical" weighs in, and then they decide which most crucial generalizations to include in the next release. At the same time, most of the FOP contributors have company-specific hacks that they've added while waiting for a general consensus to develop. It's been really interesting to watch. It's (to be completely obvious) another example of cathedral versus bazaar, because aD as you describe it (especially your workflow project) had become a bit of a cathedral. Maybe there is also some optimum proportion of developers to users for certain types of open source projects?
Read more
Read less
Reply over 22 years ago
  Cancel
Mike Arnold
 

Rule of 5, or 'pulling a Mozilla'? By the time you have implemented something (or some simillar somethings) 5 times you will have a pretty good idea how it really works; you will learn things you could not have anticipated with a single session of pre-planning. But is that the only way to learn? <p>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. <p>How is your execution of the rule of 5 not like 'pulling a Mozilla'?
Read more
Read less
Reply over 22 years ago
  Cancel
Lars Pind
 

Not quite a mozilla Mike, <p> On the contrary. First, I didn't rewrite the workflow package, so this couldn't be a mozilla. <p> 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. <p> 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. <p> 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. <p> So I still think I did the right thing :) <p> /Lars
Read more
Read less
Reply over 22 years ago
  Cancel

Leave a comment