[erlang-questions] Software Estimation and Progress Tracking

[Mahesh Paolini-Subramanya]

There are - at least - four orthogonal areas in which your software gets developed, each of which has different metrics for estimation, tracking, progress, etc., etc., etc.  To throw some semantics at this

1) Technical
When the specifics of the solution are clear, and it pretty much boils down to implementation. 
"I need to replace the valve on my Hot Tub" (With the same model, I've already done it once before, etc., etc.)

2) Engineering
When you need to solve the problem first, before implementing the solution.  There _is_ a body of kno
"I need to install my Hot Tub" (Hmmm. There is no water line going out there. How do I get one? What about the electrical circuit? Do I need architectural permission? etc.)

3) Science
You need to invent a new class of solutions for the problem at hand. 
"I need to install my Hot Tub in an underground bunker in the marshlands of Florida" (How do I build an underground bunker in the marsh? Maybe I can freeze the ground and pour concrete? How do I keep the concrete from sinking? Hmmm. Time to start running experiments…"

4) Art
You need to get the intangibles correct, viz., is it maintainable? Supportable? Documented? Elegant? 
"Will some future Significant Other like my paranoid underground-bunker hot-tub?"


Note that each of the above are _different_.  
	- Its fairly easy to Manage / Maintain / Monitor "Technical" work.  
	- There is a reasonable body of knowledge that helps in doing the same for "Engineering" stuff.  
	- For Science, its all pretty clearly made-up (the fusion reactor!), 
	- For "Art", well, it really _is_ in the eye of the beholder.  (Good Documentation? For whom? What do you mean by "Good"? *I* understand it! And so does Jane!)

Which brings me back to the original point - much as we would like it to be that way, software pretty much never fits neatly into one of the buckets above - it is some combination of the four, with different parameters for {T, E, S, A}.  
Whats worse, there is a time-variant aspect to this too - and the parameters are inter-related.  e.g., different "Engineering" solutions have different "Technical" impacts.  In short, your development process is actually f(T, E, S, A, Time)

All this being said, there is a time-honored Academic way of solving f(T, E, S, A, Time), which basically consists of wishing-away the unknowns (or make unrealistic assumptions about them) and then spend an in-ordinate amount of time on the remaining parameters.  With some appropriate tweaking of parameters, one can quite successfully make this match some "real-world" results, which can then be trumpeted widely.  Any failures can be blamed on the actors (ho-ho. "Actors". In an erlang post. I crack myself up.) who were clearly not qualified..
This may very well be the best option…

Cheers

Mahesh Paolini-Subramanya
That Tall Bald Indian Guy...
Google+  | Blog   | Twitter  | LinkedIn

On Sep 19, 2013, at 3:19 AM, Ulf Wiger <ulf@REDACTED> wrote:

> 
> On 19 Sep 2013, at 11:59, Jesper Louis Andersen <jesper.louis.andersen@REDACTED> wrote:
> 
>> Software is not "construction". It turns out to be "research". Regarding it as "construction" by imposing estimates and progress tracking is usually futile due to this dichotomy and the fact people missed it was "research".
> 
> Yes, but in my experience, this is how most research funding is determined as well: "We estimate that we will invent X in month 47 of the project, after which we will discover Y based on X in month 64, having spent N number of man-months in the process."
> 
> BR,
> Ulf
> 
> Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.
> http://feuerlabs.com
> 
> 
> 
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130919/c10b1023/attachment.htm>