Effort vs. Toolchain

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
For years I've had the graph below in my head.  I came up with it
independently, but it's just too screamingly obvious to not have been
discovered, named, and expounded about in the project management
literature.  The question about software architectures made me think of
it.

So -- anyone know if it has a common name in the project management world?

Basically, it exemplifies the notion that if you're doing a simple task,
then a simple tool will require a low amount of effort to start doing
work -- but as the task gets more complex, the incremental effort
required to get more results is high.  Contrast this to a more complex
tool that requires a large investment in effort (and perhaps training) to
even start to use successfully, but then has a much smaller increment in
effort as the task gets more complex.

I use this concept to help me make decisions between C vs. C++, sometimes
assembly vs C (if it's a _really small_ processor), task loop vs. RTOS,
polled vs. interrupt, module-buying vs. build my own, etc.

I also see this blithely ignored, often pathologically, by individuals or
management, who misunderstand the gulf between getting a lab-pig
prototype working, and getting a finished product out the door -- so a
tool will be chosen that gets something spun up and looking hopeful in
the lab, but then calls to dispense with that tool of limited scope will
be ignored because "it just works so well".

So -- what is the graph _called_?

   .
   .
   .                                    ,´
 ^ .                                   ,´
 | .                                 ,´
 | .                                /
   .                              ,´                           _-
   .                            ,´                       __-''
 e .                           /                   __--'
 f .                         ,´              __--''
 f .                       ,´           _--''
 o .                      /       _--''   <- C++, RTOS,
 r .                    ,´  __-''            machined parts, etc.
 t .                  ,´--'
   .            __--'/
   .       _--''   ,´
   .    ''       ,´
   .   |        /
   .   |      ,´
   .   |    ,´
   .   |   /
   .   | ,´
   .   ,´   <- BASIC, task loop, LEGO, etc.
   .  ||
   .  ||
   ....................................................................

                                 results -->

(created by AACircuit v1.28.6 beta 04/19/05 www.tech-chat.de)


--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
We've slightly trimmed the long signature. Click to see the full one.
Re: Effort vs. Toolchain



Quoted text here. Click to load it

Barry Boehm wrote a book documenting COCOMO a few years ago,
that would be the first place I would look. His book deals with a lot of
issues that your graph eludes to. I would look it up but my copy is
about 300Km from here right now. The other person I would ask is
Jack Ganssele who has been writing about this for some time.

You raise a number of important points that are all too often ignored
in the software development process. The switch from software
development as a black art to software development as an engineering
discipline is too often overlooked. I see it happening all the time with
our customers whose projects are in trouble because they didn't make
some real choices and account for their project requirements and
account for the application implementation requirements.

The most common missed requirements that I see are the number
of people and the team skill sets, implementation language fit to
describe a solution to the application, tool provider support and
comparing deadlines with real completion dates. Most have not
even considered the implication of software structure on application
reliability.

Some of the best managed software projects that I have seen
is in the automotive industry

Regards,


w..
--
Walter Banks
Byte Craft Limited
We've slightly trimmed the long signature. Click to see the full one.
Re: Effort vs. Toolchain

Quoted text here. Click to load it

Walter, you may be thinking of the mention in "Mythical Man/Month" for that
reference to CoCoMo. As a technique for cost comparison between projects it
is most useful when the projects share sufficient similarity. But when the
projects are very different it may lose a bit in translation.

Selection of tools has to depend very much on the project requirements.
There is a world of difference between something that is easily done with a
PLC, bunch of relays or a bespoke embedded solution (with or without GUI
HMI).

If you are gathering a team, then think of the surgical team approach
explained by Barry Boehm and the spread of skills required in the project.
The team should, of course, agree on the tools they will use to achieve the
implementation and management of the project.


--
********************************************************************
We've slightly trimmed the long signature. Click to see the full one.
Re: Effort vs. Toolchain



Quoted text here. Click to load it

Good point.

Tim's graph may be in MMM.

I was thinking of both references at the time I wrote the post and I edited the
MMM out of the post. The "Mythical Man/Month" in my opinion is a good
read and is closer to software development as a black art  where CoCoMo
is an engineering manual to software development.

w..


Re: Effort vs. Toolchain

[%X]

Quoted text here. Click to load it

The CoCoMo techniques have been around for a very long time and have their
foundation in the real engineering industry. CoCoMo's application to
software should be more widespread but I wonder how many use the technique.

--
********************************************************************
We've slightly trimmed the long signature. Click to see the full one.
Re: Effort vs. Toolchain

Quoted text here. Click to load it

I had to remind myself of what CoCoMo stood for.  The weakness that I see
in it is that you still have to estimate the required number of lines of
code -- and that's still a smoky number.

The only two methods that I've seen work with true reliability are
wideband Delphi, and comparison of an effort to an earlier, similar,
effort.

But nothing works when management says "tell me what I want to hear or
get fired", so I'm kinda cynical about _any_ method.

--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
We've slightly trimmed the long signature. Click to see the full one.
Re: Effort vs. Toolchain

[%X]

Quoted text here. Click to load it

I prefer to count up Function points. Much easier to relate to the
requirements and clearer to compare across systems using different
implementation languages.
 
Quoted text here. Click to load it

CoCoMo is sort of the comparison to many earlier efforts but hopefully in a
highly organised database for easy future reference.

--
********************************************************************
We've slightly trimmed the long signature. Click to see the full one.
Re: Effort vs. Toolchain
Quoted text here. Click to load it

   [...]

Quoted text here. Click to load it

   [...]

Quoted text here. Click to load it

Since the topic has wandered a bit from Tim's original question, I'll
add my $0.02 here on the state of the art in software development
(opinion, subject to revision).

The best recent "discussion" of this topic that I've run across
recently is Andy Oram's "Making Software: What Really Works, and Why
We Believe It". (I put quotes around the word "discussion" because
it's a collection of essays by different authors talking about various
facets of the "state of the art" in software development.)

I haven't managed a multi-person software development project for
several decades, but I have kept an eye out for things that I might
have done differently.  I bought this book out of curiosity, and an
ongoing interest in what constitutes evidence and how we justify that
claim; the content of the first and second essays ("The Quest for
Convincing Evidence" and "Credibility, or Why Should I Insist On Being
Convinced?") reassured me that I wasn't alone. <grin!>

Other essays describe research in metrics (line-counting, function
point counting, modularity, etc.), team organization, effort
estimation, team member personality evaluation, and how to improve the
instruction-to-workplace transition.

Unsurprisingly, the topic of "communication" appears frequently. "The
Art of Collection Bug Reports", for example, covers not only what
should be included in a bug report but also how to improve lines of
communication between those posting the reports and those responsible
for responding to them.

I won't recommend it as a sit-down, cover-to-cover book. <grin!>

On the other hand, the essays are fairly short (most seem to be 10-15
pages) and stand on their own.  You can skip around without any loss
of coherence.

Oh, and if anyone has access to the journal "American Scientist",
"Making Software" was the centerpiece of an article in a recent
(2011-ish) issue, although the article's authors seem to have reached
different conclusions about the reported value of "pair programming"
than what I read from the book.

Enjoy...


Frank McKenney
--
  "The purpose of a storyteller is not to tell you how to think, but
   to give you questions to think upon.  Too often, we forget that."
We've slightly trimmed the long signature. Click to see the full one.
Re: Effort vs. Toolchain

Quoted text here. Click to load it

I have to admit that my last experience with team software-writing was to
be involved in carefully building a structure where quality software got
written, tested honestly, and only released when it worked.

Then seeing the whole operation get cut off at the knees by upper
management that saw the quality assurance side of it as an unnecessary
expense.

While the place was recovering from the trauma at the point that I left,
it still pretty much made me categorically lose faith in the ability of
any developer, technical lead, or middle manager to assure software
quality.  _Everyone_ needs to be bought in to the process to have it
work, if _anyone_ -- from the lowliest hack to the company president --
doesn't see the value and utility of the process, then the whole thing is
either window dressing, or just a grand waste of time.

--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
We've slightly trimmed the long signature. Click to see the full one.
Re: Effort vs. Toolchain
Quoted text here. Click to load it

  [...]

Quoted text here. Click to load it

  [...]

Quoted text here. Click to load it

Ouch.


I can sympathize, and I have to admit that the essays in "Making
Software" don't address this; they're focussed on "do we have any hope
for improvement if everyone _does_ co-operate?".

( You've probably already heard a variant of this one:

  All the parts of the body argued over who would be boss
 
http://www.medical-jokes.com/all-the-parts-of-the-body-argued-over-who-would-be-boss /

  an oldie but appropriate in any number of places. <grin!>)


Frank
--
  "...[T]hough they saw the issues clearly and perceived the remedies,
   the sense of public duty tended to fade when the outlook was
We've slightly trimmed the long signature. Click to see the full one.
Re: Effort vs. Toolchain

Quoted text here. Click to load it
<< snip >>
Quoted text here. Click to load it

It has, hasn't it.  My original question was really motivated by a desire
to be able to convince a customer that they need to change tool sets (or
allow me to) in order for me to really be able to justify my pay.

When someone wants to get Windows CE running on a machine so that they
can then figure out how to hack Microsoft Excel so that it can make their
drapes open and close at preset times, you want to be able to talk them
down from the trees.

My magic graph would have a lot more weight if, instead of saying "in my
experience I have found that..." I can say "here's the well-known XYZ
curve, which exactly reflects your current situation...".

--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
We've slightly trimmed the long signature. Click to see the full one.
Re: Effort vs. Toolchain

Quoted text here. Click to load it

Well, I did search over at http://xkcd.com but, rather to my surprise,
this is one that he hasn't covered.

Your hypothesis is pretty intuitive -- consider MS Word versus LaTeX --
and, yes, somebody must have written it up.

Obligatory xkcd link
http://imgs.xkcd.com/comics/nerd_sniping.png

--
Rich Webb     Norfolk, VA

Re: Effort vs. Toolchain
Quoted text here. Click to load it

Ratzenfrazzle. Preempted on another wonderful concept. <grin!>

Guess my idea for an alarm clock based on a .NET "rooster-crow
detector-via-FFT" that triggers a USB-connected, solenoid-driven gong
is out, too? Sigh.

Quoted text here. Click to load it

Well, Tim...

I don't think I can help _you_, but from here on in _I_ can talk about
the "well-known Wescott Curve..."  <grin!>


Frank
--
    It is better to wear out than to rust out.
                 -- Bishop Richard Cumberland
--
Frank McKenney, McKenney Associates
Richmond, Virginia / (804) 320-4887
We've slightly trimmed the long signature. Click to see the full one.
Re: Effort vs. Toolchain



Quoted text here. Click to load it

One thing that I have seen is many of the asian development shops seem
too be able to estimate the number of lines of code much more accurately
than development shops in North America

Part of the reason appears to be their requirements attention to detail.

One thing that we started to pay attention to is developers estimates
are often wrong but the relative numbers for code or development time
are many times quite accurate. In one project we accepted all the estimates
we were given by the developers un questioned and early in the project
used parts of the project to calibrate the estimates and apply to the
uncompleted application. In one project involving about 60 people for
10 months the estimated completion time and code size was accurate
within a few percent about 6 months before completion.

w..





Re: Effort vs. Toolchain
Quoted text here. Click to load it
 <- C++, RTOS,
Quoted text here. Click to load it

I believe you can include one more curve. Not a lot of statistics for
it,
of course, but it is a valid one nonetheless.
This is the case where a house uses an own toolchain.
Obviously it will start much higher than the two curves you already
have but I think it can have regions with negative slope and
will go much below the other two after some point.

Here is an example - a one-off project I did recently using an
MCF52211. It took me a total of 4 months, design and PCB routing
included (that was the first 45 days, including waiting for the PCBs
and finishing other tasks I had started while waiting for the PCBs).

Then I had no toolchain ready for the coldfire and for this part in
particular. Modifying the assembler was minor (it was for CPU32), I
had
only to cut opcodes and addressing modes out.
Writing some BDM tool was what took about two months IIRC (may be a
bit
less), then writing the actual application code took about another
month (perhaps a bit more).
After that the device was just delivered.

May be this curve is not only about toolchain, it is also about the
willingness of the toolchain user to learn and to acquire skills
over the years. It does take quite a number of years to get there,
of course.

To illustrate the above:
BGND coldfire debugger:
http://tgi-sci.com/misc/cfb.gif
Device: http://tgi-sci.com/misc/PICT6993.JPG ,
http://tgi-sci.com/misc/PICT6999.avi
Board:
http://tgi-sci.com/misc/swgboard.gif

Dimiter

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276 /



Re: Effort vs. Toolchain

Quoted text here. Click to load it

And why didn't you use the Freescale toolchain?

Bye Jack
--
Yoda of Borg am I! Assimilated shall you be! Futile resistance is, hmm?

Re: Effort vs. Toolchain
Quoted text here. Click to load it

Freescale doesn't make a toolchain suitable for his needs.  Not everyone
uses C or C++.

Site Timeline