just curious folks to what folk use to help develope their software with.
I am an avid user of lint and having a go at trying to design what i am gonna do before i start being a code monkey but would like to find out what others are using.
Recently downloaded Tessy but as i get the feeling trying to apply it to an exsisting project will be a huge project its self and as the vendors havent been rushing to reveal the price cost may be an issue.
Does anybody have any recomendations on tools they find useful?
Some-one recommended me this book:
"Test Driven Development for Embedded C" pragprog.com/.../test-driven-development-for-embedded-c
Might be worth a read.
Interesting looking book - thanks for the recommendation.
@Mike Kleshov,
Been to a one day course introduced by some academics about that subject exactly. I have a lot of respect for the academy, but that session was a demonstration of "how to write code that will never ever fit into small foot prints" and "how to make software development so expensive that it is not even worth starting (due to test model maintenance costs etc.)." I have used similar techniques in the past; they work and help like charm. But go figure how to get that into a LPC1114 that has a fully loaded ROM/RAM.
"Test Driven Development for Embedded C"
"succesful testing does not prove the absence of bugs, it proves the absence of known bugs" source unknown (to me)
Erik
that session was a demonstration of "how to write code that will never ever fit into small foot prints" and "how to make software development so expensive that it is not even worth starting (due to test model maintenance costs etc.)." I recall an incident where I was asked to help a copuple of recently hired 'academics' do banking with the '51 because they had run over the 64k space. I had a look, threw them out and made the app fit in about 8k
Good quote Erik. Somewhere I heard that a quality number should be five 9s (99.999%). For a 1000 line code we are guaranteed at least one bug. Also, I have read a "reasonable" line of code produced an average about 17 bytes of code. I'm not sure if the 99.999% should be applied to the lines of code or the bytes of code. Never mind. A 64Kbyte code file sould produce about 3.5 bugs. I don't know how you get 0.5 bugs.
Quality metrics are fun and sometimes ridiculous.
But I know that good tools don't cost - they pay in the long run.
Bradford
IBM Seeks Patent On Judging Programmers By Commits yro.slashdot.org/.../ibm-seeks-patent-on-judging-programmers-by-commits (I have not read the comments in above link.)
what IBM seeks to patent has been a metric in many organizations for ages - agreed, somewhat imprecise. That Itty Bitty Machine Co has made a program should not allow them to patent the method
BTW the metric is ridiculous in many cases. You are to be judged on how many changes you make to something you have committed. How often have you been forced to commit against your better knowledge because "It has to go out the door today". I doubt very much the program IBM has made will take that into account. Also, you commit 'perfect' code and have to 'uncommit' because some spec changes, what about that.
We have so many things that are made to make management believe they can schedule precisely (agile, waterfall, ....) they all have pros and cons, but all suffer from the illusion that software development time can be estimated precisely.
software quality / finding and retaining quality talent
ISO technical committees TC 260 Human resource management www.iso.org/.../pressrelease
Safer C: www.saferc.com/.../
Les Hatton: http://www.leshatton.org/