What percentage would you say your current project consists of software reuseable items?
By software reusable items I mean something that you acquired (purchased, freeware, shareware, licensed etc) which you had no responsibility in the development, construction, or testing. You reused them because the documentation was sufficient to convince you of its quality.
0 percent.
If you use software from a third party, then /you/ are responsible for testing and otherwise qualifying it for use in /your/ system.
Getting the software parts from somewhere you consider reliable will certainly /reduce/ the level of testing you need to do to be happy with its quality, but it does not eliminate it.
If you buy your chips from a reliable supplier, and they come with good datasheets qualifying temperature ranges, power requirements, etc., does that mean you don't have to test your boards when you use them? It might mean you don't have to test over a wide temperature or voltage range, but you still have to test the boards.
The same thing applies to software components.
If the documentation is *that* good, then the vendor should be GLAD to *warrant* it's performance! Hey, *he* wrote the spec, right? Shirley, he'd be glad to put his money/reputation behind his product if he's *that* confident in its quality -- since you are adopting it "because the documentation was sufficient to convince you of its quality". (Isn't it sufficient to convince *him*?)
+42 [1]
Early on in my freelance career, I tried leveraging other folks' work "off the shelf". The quality of the products I encountered was just laughable. The (ahem) "documentation" was little more than sales brochures. To truly quantify (and qualify) the performance meant pouring over the code, line by line, to see what it *thinks* it's doing, and how. [2][3]
I think much of this is attributable to the fact that these things aren't, often, *designed* as "products" but, rather, someone says (after-the-fact), "Now that this seems to work, why don't we sell this as a product?". Would you buy an automobile from some guys who, tinkering, put one together in their garage, and (sort of) got it working? "Um, what weight motor oil does the engine *need*?" "Well, we used 10W40" "Yes, but is that what the engine *needs* or just what you happened to HAVE ON HAND?"
If I'm going to buy (rely upon) a "product", I'd like to *see* that it was "thought out" and designed in a systematic fashion. That should include formal specifications of how it is *intended* to work plus *proof* that it does, in fact, work as intended.
If you are expecting *me* to deduce the specifications from "educated guesses and empirical observation" AND then have to prepare a test suite to convince myself that this is, indeed, the case, then what *value* are you adding? ("Oh, we wrote the *code*!" "Pshaw. Big deal.")
IME, when it comes to "reuse", the biggest bang comes from
*design* reuse rather than actual *code* reuse. I worked at a firm in the early 80's that pushed the concept of code reuse aggressively (all of our software had "part numbers" and was treated as "Standard Product"). But, it was a joke because you *never* reused a piece of code "as is" (even though you *owned* it) because each project was slightly different [granted, in that timeframe, we were squeezing lots of performance into very small packages so it was actually worthwhile to trim a few bytes here and there]-------------------- [1] That's changing in some of the projects I have ahead of me that incorporate *large* pieces of OSS. But, I have actively watched the development and maintenance of those projects for many years, now, and am confident in the quality of the code produced as well as the goals of the "primary players".
[2] I had a reasonably pleasant experience with a (text) display system produced by "The Aspen Codeworks" (apologies if I have misremembered this). There was no "test suite" but, rather, some simple examples (all of which, I think, worked). And, the author was helpful enough to get me going in the right direction to modify it to better suit my needs. [3] I also evaluated some library products from that seemed quite professionally done. But, they didn't fit my needs. :<
Many of us would have problems recognising that as a definition of re-use. Your definition is more like COTS* usage to me.
If you really want to talk about re-use then perhaps you can look to a better definition first and then ask the question again.
By my notion of re-use I would put the percentage in my projects at somewhere between 30% and 60% depending on the project being undertaken.
*Commercial Off-the-shelf-- ******************************************************************** 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.. ********************************************************************
I'm trying to remember the last time I bought software that was warrantied. I think the answer is never. And stop calling me Shirley. (:
That's my point. The OP is asking us to be "confident" enough from the *documentation* (alone) that we are "assured" that the product is worth incorporating into SOMETHING THAT *WE* WILL END UP WARRANTYING (at some level) and/or risking our income or reputation on... yet, the vendor himself doesn't have that same level of confidence in something that he *defined* (specified) and has intimate knowledge of its implementation?
"Yes, we have no bananas"
Agree.
Same for me - In my current project I would say 70% of the code is reused. Most of it is in common libraries developed in-house for other projects in the same product line.
-- Roberto Waltman
[ Please reply to the group. Return address is invalid ]
You write your libraries from scratch, or do all your work in assembly?
-- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.html
I'm currently reusing software that I've written. I'd like to say that I'm not modifying it, but it is getting tweaked a bit. Beyond that I'm coding in C++ and using the libraries that come with the gcc ARM compiler.
In the past, when I worked at a medium-large company that had big projects with product life that pushed a decade, I was part of a team that did a considerable amount of reusable library code. It then got successfully re-used, so we must have done something right.
-- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.html
I don't use much third-party code (for small systems - the balance is different for larger systems). Obviously there is some library code with the compiler (especially language support code), though I don't tend to make much use of the standard C library.
But my point is not that I or anyone else doesn't use third-party code - just that if I use third-party code in my project, then /I/ have a responsibility for testing, and making sure it is suitable for the job. The OP seems to think it is appropriate to take other people's code and use it, and let /them/ be responsible for any failures.
Obviously the amount of testing and qualification you do with the third-party code depends on its source, and the type and quality of the code. You can generally rely on your compiler's integer division routines to give the correct result - but you would want to be a lot more careful about some code you found lying around on the internet or bought from a vendor you are not sure about (price is no indication of quality).
I was only yanking your chain about your "0 percent" -- the rest of it I agree with, wholeheartedly.
Even something as supposedly intrinsic as floating point code can't be trusted -- the early Code Composter library for the TMS320F28xx processor had a bug where numbers that were very close to an integer power of 2 would get doubled (or halved, I can't remember) when rounding to an integer, so 0.999999999 would end up as 2.0 (or 0.5), 254.99999999 would end up as 512 (or 128), etc.
It was a royal pain in the behind, and fortunately they fixed it. But the only comment I can add to your "you can't trust nothin'" is "that's right -- and you can't trust anything else, either".
-- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.html
[disclaimer: I write for a wide variety of application domains, target hardware, etc. so my project-to-project needs vary considerably. If all of your projects "are the same", then you're experiences will be different]
No to the assembly part but yes to the library query.
First, I tend to write my embedded projects *strictly* in C (though I often use some esoteric "blend-ins"). And, most tend to be "trimmed to fit" the resources available -- not likely to have much of *anything* "to spare".
If you're developing in C++, my condolences -- I've yet to meet the guy who can look at N pages of C++ code, identify all the anonymous objects, every (invisible) constructor/destructor instantiations, etc. and tell me, authoritatively, what that code will behave like at run-time. I usually can't afford to have "surplus stack/heap/cpu" to cover the "unknowns".
Looking just at the C libraries, consider:
- do you use the float/double support in printf? scanf? Or, their support for long arguments? Or pointers? Take a peek at how much bloat is associated with their presence in those functions. For each format that you *don't* need, does your bastardized printf/scanf check for errors in the format string? (or, do you just let that creep into your product as a "bug"?)
- what does your I/O system look like? Where does printf() send its output? A UART? text display? bitmapped display via a font rendering library? Likewise, where does getchar() fetch its input from? Do you even *have* a "keyboard" -- or is user input from a set of dedicated switches?
- do "stdout" and "stdin" really exist as entities? Can you redirect them to other physical devices? Is fprintf(stdout...) really the same as printf()? Or, is everything hardwaired (in practice) with lip service given to the mnemonics?
- do FILE*'s (and related functions) make sense in your world? Can you *share* them among tasks (locking, etc.)? Or, is the behavior "undefined" when competing tasks access them?
- how do you implement resource locks? Is your OS API always consistent (so that the "lock_device(foo)" statement in the stdio library behaves the same across platforms)? Do your tasks *share* a heap (which implies some sort of locking)? Or, do you allocate a heap per task?
- ditto re: errno. Or, has some "standard" forbidden you from ever identifying the cause of your errors? :> What happens if another task invokes a function that alters errno?
- is there any concept of "system()" in your environment? Is there an *environment* in your environment? :> Who catches exit()'s result? etc.
- are you working in a flat memory model? is there an underlying VMM system? are there *holes* in the memory map (hint: "yes")? How do your libraries deal with these issues -- have you come up with an implementation that fits universally? Or, do you just let the deviations from one environment to the next result in *bugs*?
- do things like memmove() and memset() know how to take advantage of the capabilities of the particular processor (or, do they unconditionally resort to byte operations)?
- do you allow the str and mem functions to operate on pointers that reference "read only" memory? E.g., is it a bug to strcpy to ROM? What about *from* ROM? What about accessing arguments that reside in a stack frame or on the heap... can one of these functions walk "past the end of physical memory"?
Unless you've thought about how each function interacts with your environment (neglecting the fact that the environment might change from project-to-project), then you are leaving your code vulnerable to more post-release bugs -- especially if you don't have a thorough test plan in place (which I suspect is the case with many projects).
The libraries that I release with a project are tailored to
*that* project. They know the requirements and *assumptions* that are appropriate for that project and live within those confines (often deliberately exploiting certain characteristics of those environments to make the code faster/simpler).That's not to say the code doesn't *resemble* its counterparts in other projects. Indeed, comparing two versions of "the same routine" often highlights the assumptions or exploits in each.
To sum up, I think it behooves every developer to examine the libraries that they use so they understand the costs and vulnerabilities associated with each of those function invocations that they often make so "casually". And, if you tend to use more "esoteric" characteristics of those routines, you might surprise yourself to discover the cases where they
*fail* (my favorites tend to be things along the lines of printf("%.*Lf", MAXINT, 1.0L/3.0) -- which, unless I have misremembered the syntax, here, *should* work on all conforming implementations! See how *yours* fares :> )
While I understand (both) your point, I can see the OP's intent, here. How do you differentiate a third party COTS product from a product that the guy who sat in your cubicle *last* year wrote!?
A necessary prerequisite for reuse is a complete "understanding" (documentation) of what that code does and is intended to do and what it *won't* do. And, in which environments those claims apply.
I think that is a ^^^^^^^^^^^^^^^^^^^^^^^ key factor. If your projects/products are similar, then you can benefit from reusing code written (designed) to solve a "very similar problem" in a sister product. Because the needs *tend* to be the same and the
*environment* tends to be the same.I wouldn't, for example, feel comfortable porting code from a data logger that was designed to run on stripped down hardware to a "PC platform"...
Perhaps, but it's a fair point. Many people don't realise that a compiler library (both the support library, and the C library) is also third-party code.
/All/ versions of Code Composter (can I borrow that name?) have a serious design flaw - uninitialised statically allocated data, which should be initialised to 0 according to the C standards, is left uninitialised. That caused me a lot of pain before I discovered it was the CCS compiler that was flawed, not my code.
I know that the uninitialized statically allocated data is work-aroundable, but you have to write some startup code to make it happen.
Unfortunately I'm not the one who wrote the startup code -- I was software lead on that, doing head-in-the-clouds control loop and communications protocol code, while a really sharp fellow I worked with actually found the problem and made it go away.
And yes -- you're welcome to use that name. I actually tried to learn where the thing stored it's splash screen, so I could turn
C O D E C O M P O S E R
into
T v C O D E C O M P O S E R
Reason (and a tight project schedule) intervened, however.
-- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.html
Huh? Can't you fix that in crt0.s?
But to qualify it you have to test the boards, not the chip. There is a difference between system validation and component testing, when you buy a chip where you involved in the gate level testing? No. Do you perform gate level testing of the chip when you get it, no. You treat the chip as a black box, completely unaware of it's development cycle, layout history, or testing. You make no attempt to repeat the suppliers chip level testing and generally don't have any desire to know what they did (and is generally intellectual property so you couldn't find out if you wanted to).
What you do is you plug it in your system and verify your system meets customer specs. Your job is to verify it performs while interacting with other components in the system. That is your testing responsibility.
Same would be true with reuseable code, you test the system, not the inners of the reuseable code. You qualify it the same way without the line by line testing. So your argument isn't valid.
.
no, I knew exactly what I was asking.
.
Yes I would consider the libraries true reuse as well as types.
Tweaking your own code, not reuse, maybe junk yard salvage :). Much better then starting from scratch though.
use.
But why? We don't require this strict "complete understanding" for HW components. Some HW datasheets are wrong, components don't work as stated, they are returned for failure analysis etc etc. But we deal with it. We build systems that work because we test at a high level. We still build reliable systems with all these headaches.
For SW, the attitude (from the responses here and my personal experience) is it has to be guaranteed to work 100% or otherwise I'll just code it myself. And this attitude exists for 3rd party SW as well as for 1 year old software done in house by the guy who sat in the cube next to you, like you mentioned.
There is a process to deal with defective COTS SW like defective HW.
n.
Yes exactly, that is the typical "reuse" I normally encounter.
Only occurs if very similar projects, same product line or small enhancements to a product. I don't call that reuseable code. I mean, what else would you do if you have to enhance a product line, throw everything out and start over? Any code, no matter how badly it's written can be used in situations like that. Call it what it really is, a point (custom) solution modified to be another point solution for a similar product.
Reuseable code is code that can be used in a completely different product as is.
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.