benchmarking: the shootin

well, i've set up a public benchmarking suite on sourceforge. my first open source project (other than a file or two published here and there)

http://shootin.sf.net/

at this stage, it's barely functional. hopefully skaller can give me some feedback so i know where to start refining it.

it's been an interesting experience to start a project. it's not that it's the first time i've started something substatial, but i've been more reflective this time round. i notice my code expanding, but is it expanding in the right places? the answer to this is that you don't know if it's expanding in the right direction unless it's 'use case driven'. i'm not a big fan of formal modeling (lots of diagrams and words) but 'use case' is the best basis for developing, methinks.

that is, say i've got a few features of a new program i'm developing called 'cvs'. cvs takes an argument from {import,checkout,update}. so the first thing i do is implement 'cvs import'. once i get this working, run 'cvs checkout'... etc.

this may seem obvious, but sometimes we get stuck in a bottomless pit. for example, you're not sure how to get a recursive 'update'. instead of thinking recursion, go to a simpler use case. say, 'cvs update source.c' and implement this use case. 'cvs update .' will come easier this way.

it's called 'bottom-up' i think.

anyway, i'll be keeping this in mind as i'm working on the shootin.