1. Home
  2. Embedded Programming
  3. Effort vs. Toolchain

Effort vs. Toolchain

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 . / _--''

Reply to
Tim Wescott
Loading thread data ...

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

formatting link

Reply to
Walter Banks

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.

--
********************************************************************
Paul E. Bennett...............
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************
Reply to
Paul E. Bennett

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..

Reply to
Walter Banks
[%X]

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.

--
********************************************************************
Paul E. Bennett...............
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************
Reply to
Paul E. Bennett

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.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com
Reply to
Tim Wescott
[%X]

I prefer to count up Function points. Much easier to relate to the requirements and clearer to compare across systems using different implementation languages.

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

--
********************************************************************
Paul E. Bennett...............
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************
Reply to
Paul E. Bennett

[...]

[...]

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.

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.

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."
                   -- Brandon Sanderson / The Way of the Kings
Reply to
Frnak McKenney

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.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com
Reply to
Tim Wescott

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.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com
Reply to
Tim Wescott

Well, I did search over at

formatting link
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

formatting link 

--
Rich Webb     Norfolk, VA
Reply to
Rich Webb
[...]

[...]

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

formatting link

an oldie but appropriate in any number of places. )

Frank

--
  "...[T]hough they saw the issues clearly and perceived the remedies,
   the sense of public duty tended to fade when the outlook was
   depressing or the political necessities distasteful."
                         -- Barbara Tuchman / The March of Folly
Reply to
Frnak McKenney

Ratzenfrazzle. Preempted on another wonderful concept.

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.

Well, Tim...

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

Frank

--
    It is better to wear out than to rust out. 
                 -- Bishop Richard Cumberland
Reply to
Frnak McKenney

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..

Reply to
Walter Banks

?

=A0 =A0,=B4

=A0 ,=B4

=B4

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 _-

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 __-''

=A0 =A0 =A0 =A0 =A0 =A0 __--'

=A0 =A0 =A0 =A0__--''

=A0 _--''

=A0r . =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0,=B4 =A0__-'' =A0 =A0 =A0 = =A0 =A0 =A0machined parts, etc.

..

s -->

ttdesign.com

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:

formatting link
Device:
formatting link
,
formatting link
Board:
formatting link

Dimiter

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

formatting link

------------------------------------------------------

formatting link

Reply to
dp

And why didn't you use the Freescale toolchain?

Bye Jack

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

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

Reply to
David Brown

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.