Comments for James Grenning's Blog http://www.renaissancesoftware.net/blog Blogging about Agile Development, especially embedded. Follow me on twitter: jwgrenning Sun, 29 Nov 2009 06:18:45 -0700 http://wordpress.org/?v=2.8.5 hourly 1 Comment on Extra! Extra! TDD Doubles LOC and No One Cares! by Wisang Eom http://www.renaissancesoftware.net/blog/archives/46/comment-page-1#comment-746 Wisang Eom Sun, 29 Nov 2009 06:18:45 +0000 http://www.renaissancesoftware.net/blog/?p=46#comment-746 Quite an intersting topic. I found out that, in some organization, the average LOC developers write a day is around 10. The time for writing 10 Lines of code is trivial. Even though it is doubled, it is trivial too. Most of the time is spent on debugging and finding solutions for fixing the bug in a safe way. TDD doubles LOC. That's true. But the test code does not get into target. So, no physical problem. Also the time for doubling the code is just trivial but the code quality is improved dramatically so that the totoal time can be saved. LOC is doubled but it is at least free and you may get considerable profit from it if your are skilled with TDD. Quite an intersting topic. I found out that, in some organization, the average LOC developers write a day is around 10. The time for writing 10 Lines of code is trivial. Even though it is doubled, it is trivial too. Most of the time is spent on debugging and finding solutions for fixing the bug in a safe way.

TDD doubles LOC. That’s true. But the test code does not get into target. So, no physical problem. Also the time for doubling the code is just trivial but the code quality is improved dramatically so that the totoal time can be saved. LOC is doubled but it is at least free and you may get considerable profit from it if your are skilled with TDD.

]]> Comment on Embedded Memory Constraints and TDD by Mark http://www.renaissancesoftware.net/blog/archives/72/comment-page-1#comment-725 Mark Wed, 11 Nov 2009 00:44:24 +0000 http://www.renaissancesoftware.net/blog/?p=72#comment-725 Nice post, James. We have our continuous integration server tracking peak heap and stack usage, overall memory footprint, and peak cpu. Currently all that stuff just gets stored with the test results... so if we're passing, we don't pay attention. I love the idea of having these go onto a BVC... especially if we can make that BVC automatic. Thanks for the idea! Nice post, James.

We have our continuous integration server tracking peak heap and stack usage, overall memory footprint, and peak cpu. Currently all that stuff just gets stored with the test results… so if we’re passing, we don’t pay attention. I love the idea of having these go onto a BVC… especially if we can make that BVC automatic. Thanks for the idea!

]]> Comment on Extra! Extra! TDD Doubles LOC and No One Cares! by Mark T http://www.renaissancesoftware.net/blog/archives/46/comment-page-1#comment-722 Mark T Sun, 01 Nov 2009 14:24:47 +0000 http://www.renaissancesoftware.net/blog/?p=46#comment-722 I agree that Lines of code (LOC) has always been a bad metric but many organizations still use it for bidding purposes. Maybe some day "story points" will be the way to bid but they are still yet another fuzzy widget. When using LOC the real metric should be WDLOC (working deliverable lines of code) no claims of "error free". The cost metric is the time to produce a WDLOC. Which for embedded systems, I would say a TDD approach would come out cheaper overall. Pay me now or pay me later. The "unit" test code itself should never be counted as LOC that is just a cost of producing the working deliverable code along with debugging and SW/HW integration. I agree that Lines of code (LOC) has always been a bad metric but many organizations still use it for bidding purposes. Maybe some day “story points” will be the way to bid but they are still yet another fuzzy widget. When using LOC the real metric should be WDLOC (working deliverable lines of code) no claims of “error free”. The cost metric is the time to produce a WDLOC. Which for embedded systems, I would say a TDD approach would come out cheaper overall. Pay me now or pay me later. The “unit” test code itself should never be counted as LOC that is just a cost of producing the working deliverable code along with debugging and SW/HW integration.

]]> Comment on Now I’ll really use test driven development to write device driver code by James Grenning’s Blog » Blog Archive » Why Test Driven Development for Embedded? http://www.renaissancesoftware.net/blog/archives/8/comment-page-1#comment-718 James Grenning’s Blog » Blog Archive » Why Test Driven Development for Embedded? Sat, 24 Oct 2009 13:07:33 +0000 http://www.renaissancesoftware.net/blog/?p=8#comment-718 [...] can TDD to the hardware, see these two articles: Who says you can’t test drive a device driver? Now I’ll really use test driven development to write device driver code Progress Before [...] [...] can TDD to the hardware, see these two articles: Who says you can’t test drive a device driver? Now I’ll really use test driven development to write device driver code Progress Before [...]

]]> Comment on Why Test Driven Development for Embedded? by jwgrenning http://www.renaissancesoftware.net/blog/archives/55/comment-page-1#comment-712 jwgrenning Fri, 16 Oct 2009 01:23:41 +0000 http://www.renaissancesoftware.net/blog/?p=55#comment-712 I can't say about CatsRunner, but If you are using the GNU tool chain, you might want to look at <a href="http://www.cpputest.org" rel="nofollow">CppUTest</a>. Another good test harness of unity. I can’t say about CatsRunner, but If you are using the GNU tool chain, you might want to look at CppUTest. Another good test harness of unity.

]]> Comment on Why Test Driven Development for Embedded? by Alan Dayley http://www.renaissancesoftware.net/blog/archives/55/comment-page-1#comment-709 Alan Dayley Wed, 14 Oct 2009 23:06:29 +0000 http://www.renaissancesoftware.net/blog/?p=55#comment-709 Nice description of TDD benefits. We have a team starting to talk about TDD, but they are still skeptical. This will be lots of food for discussion! @David The page for CATSRunner shows the latest version at 2005. The system sounds exciting and dovetails into our desire to move development on to GNU tools. Is CATSRunner still alive or just on life support? Nice description of TDD benefits. We have a team starting to talk about TDD, but they are still skeptical. This will be lots of food for discussion!

@David
The page for CATSRunner shows the latest version at 2005. The system sounds exciting and dovetails into our desire to move development on to GNU tools. Is CATSRunner still alive or just on life support?

]]> Comment on Why Test Driven Development for Embedded? by jwgrenning http://www.renaissancesoftware.net/blog/archives/55/comment-page-1#comment-704 jwgrenning Sun, 11 Oct 2009 15:12:30 +0000 http://www.renaissancesoftware.net/blog/?p=55#comment-704 I think your final point (slightly edited :-)) is that more testing might mean more field updates can be prevented. I think your final point (slightly edited :-) ) is that more testing might mean more field updates can be prevented.

]]> Comment on Why Test Driven Development for Embedded? by David Kramer http://www.renaissancesoftware.net/blog/archives/55/comment-page-1#comment-702 David Kramer Sat, 10 Oct 2009 20:23:51 +0000 http://www.renaissancesoftware.net/blog/?p=55#comment-702 I'm glad to hear such sentiment. A few years ago I and two others started a company (http://www.agilerules.com) focused on Agile coaching, training, and readiness assessment, but with a target market of the embedded world. We created an open source tool for unit and acceptance testing embedded code with an unusual twist; We used GDB's ability to communicate with the board to drive the testing from the host computer, so which tests got run was controlled by the host, only the data for the current test need be on the board's memory, and results were captured on the host and a red/green HTML page generated from it. It was called CATSRunner (http://www.agilerules.com/projects/catsrunner). I will admit we didn't get many customers in that market, but we got a lot of interest. Now that Agile and TDD are more accepted, I hope more people see the wisdom of more testing. With embedded in so many consumer and in-the-field products, "upgrading is a xxxxx". I’m glad to hear such sentiment. A few years ago I and two others started a company (http://www.agilerules.com) focused on Agile coaching, training, and readiness assessment, but with a target market of the embedded world. We created an open source tool for unit and acceptance testing embedded code with an unusual twist; We used GDB’s ability to communicate with the board to drive the testing from the host computer, so which tests got run was controlled by the host, only the data for the current test need be on the board’s memory, and results were captured on the host and a red/green HTML page generated from it. It was called CATSRunner (http://www.agilerules.com/projects/catsrunner).

I will admit we didn’t get many customers in that market, but we got a lot of interest. Now that Agile and TDD are more accepted, I hope more people see the wisdom of more testing. With embedded in so many consumer and in-the-field products, “upgrading is a xxxxx”.

]]> Comment on Who says you can’t test drive a device driver? by James Grenning’s Blog » Blog Archive » Why Test Driven Development for Embedded? http://www.renaissancesoftware.net/blog/archives/7/comment-page-1#comment-698 James Grenning’s Blog » Blog Archive » Why Test Driven Development for Embedded? Wed, 07 Oct 2009 17:02:52 +0000 http://blog.renaissancesoftware.net/?p=7#comment-698 [...] you want to see how close you can TDD to the hardware, see these two articles: Who says you can’t test drive a device driver? Now I’ll really use test driven development to write device driver code Progress Before [...] [...] you want to see how close you can TDD to the hardware, see these two articles: Who says you can’t test drive a device driver? Now I’ll really use test driven development to write device driver code Progress Before [...]

]]> Comment on Planning Poker Party (The Companion Games) by jwgrenning http://www.renaissancesoftware.net/blog/archives/36/comment-page-1#comment-697 jwgrenning Thu, 01 Oct 2009 18:34:04 +0000 http://www.renaissancesoftware.net/blog/?p=36#comment-697 Fabrice thanks for the translation! James Fabrice

thanks for the translation!

James

]]>