Comments on: True Working-ness

By: Blog Pav Blog › The Shorter Timescale

Blog Pav Blog › The Shorter Timescale — Thu, 03 Dec 2009 23:47:46 +0000

[...] covered the idea of working software in a previous blog post but “preference to the shorter timescale” idea deserves some [...]

By: pav

pav — Thu, 03 Dec 2009 14:45:23 +0000

Thanks Alex and Patrick for your comments! I’ll try to address them here but they both deserve further thought.

Alex wrote that my definition of true working-ness is high level and vague while Patrick pointed out that nothing is really working until the end user says so.

Both of these comments point out the fundamental flaw in the idea that software is ever “finished”.

I would argue that “finished” and “working” are two different things. Working software is just that–not done but ready for deployment. (I hope that’s what I said in my original blog post!) Finished software is complete in all senses of the word from both inside (requirements implemented) and outside (user acceptance).

Thanks for clarifying my thinking

By: Patrick Delfert

Patrick Delfert — Thu, 03 Dec 2009 04:54:51 +0000

I agree with your emphasis on working software, and I’d add that software needs to have actually been used by end users, and not just internal users, for it to really be “working”.

By: Alex

Alex — Sat, 28 Nov 2009 02:34:18 +0000

True and makes sense… question is – how do you define that true workingness. I think management that follows any methodology often concentrates too much on the high level, derivative metrics of success. I hasn’t fully formulated that in my head, but feels like ‘if you want to go on vacation, you leave things in a good state and others can pick it up while you are gone’ is very vague and that is where problem often comes from. My understanding of this differs from other people’s understanding of this, as well as my metrics for reliability. While I can say if(x > 0) then x=0 is perfect piece of code, other people will say it is not. It is not commented it is not checking for x to be not null, etc. etc.
So…what I am trying to say here, without underlying, very well defined metrics for workingness, it is hard to achieve it.

IMHO defining a low level requirements for the system that are driven by high level requirements(think workingness) is an important part of iterative development, or even pre-development actually. Very unagile seems like… However this strict underlying level of constraints, when enforced(this is important(!!!) otherwise it doesn’t work) allows to create environment where higher level agile workingness could be actually better defined and thus easier achieved and better tracked.