About jwgrenning

Hi I've been developing and managing software for decades now. Starting in embedded, but doing more than embedded. Many of the mainstream software development techniques have crossover value to embedded. My mission is to spread some of those techniques to the embedded community. My company is Wingman Software. Please visit my site.

TDD and the Big Framework Part II

In TDD next to the Big Framework we looked at a design that helps to isolate your code from the BigFramework. That article only showed half the story. Lot’s of times the big framework has the attitude “don’t call us, we’ll call you” built right in. Your code has to register somehow with the framework, then when you ask it to do things, it calls you back, asynchronously, with the result.
Continue reading

Coaching ramblings from China

I’m just completing my fourth trip to China to coach Chinese engineers in TDD. I’ve learned a few things, I hope, about coaching people who don’t speak my language as a first language. I also had occasion to use what little I know on the subject while at the Scrum gathering in Shanghai, the first in China. Before I get into that, let me tell you about my adventure getting the the Scrum gathering.
Continue reading

Speak to me Vikki

My friend Bas introduced me to Vikki, the computerized text-to-speach voice on my Mac. I had met her once before but thought, what good is she? I don’t need text-to-speech.

Vikki is becoming a very valuable companion helping me to write my book on TDD for Embedded C. Like many writers I have heard from, I find it very difficult to find problems with what I have just written. Jeff Langr suggested reading out-loud as part of the proof reading process. That helped a lot. But I often still read what was in my head rather than what was on the page.

With Vikki by my side, I can select a paragraph and have her read to me. She sounds a little like a Scandinavian that has had a few, but she actually reads what is there on the page. I even have discovered
I can edit out the problems as she is reading.

Thanks Bas. Thanks Jeff. Thanks Vikki.

TDD next to the Big Framework

TDD next to the Big Framework

We’re trying to create a new executable process that plugs into a pretty big services framework for a telecom system. Our code and framework are in C++. We’re test driving our design. Within a few tests, we were confronted with having to inherit from a framework class. No big deal, or so we thought. Soon the dependency chains became evident. Kind of like this picture, but worse. Continue reading

Agile 2008 – Wisdom of Crowds Keynote and Planning Poker

At Agile 2008 James Surowiecki, the author of Wisdom of Crowds, gave the opening keynote address. If you have an opportunity to hear him speak, take it. He did a great job. No power point slides with a compelling style and message. Continue reading

Story Points win Over Ideal Days

Should a team use story points or ideal days for estimation. Story points have clear advantages.

An ideal day is this thing that never happens. You get to work, everyone else took the day off, except when you need to ask them a question, then the needed person is immediately available and willing to help you. On this ideal day your goals are clear and so is your head. So really, there is no such thing as an ideal day except in our imagination. Continue reading

Bug Fixes and TDD

Code has bugs. Finding a bug’s hiding place is a challenge. And, you know that killing a bug often breaks code in unexpected ways, hatching more bugs to discover, hunt down, and kill.

If you created your whole code base using TDD, you could prevent many of these new bugs. But you have legacy code; code without tests. How should the professional software Orkinman apply DDT, I mean TDD, to bugs in existing code. (Orkin (r), do i have to do this in a blog?)
Continue reading

Physics of Test Driven Development

Test Driven Development is a challenging practice. Why should you bother to learn it? You should learn it because it is a productive and predictable way to develop software.

Let’s compare TDD to the most popular way of programming, something I call Debug Later Programming. In DLP, code is considered “done” after it is designed and written. After the code is “done” it is debugged. Hmmm. Interesting definition of done isn’t it? The definition fails to include about half the effort.

Continue reading

Tests vs. Short Term Cache Between Your Ears

You have someone else’s code. You have to use it. To use it you have to learn it. If the code had automated unit tests you could read the unit tests to see how the code behaves. But, it probably does not have unit tests. So, you read the documentation. The documentation usually leaves some room for interpretation in the best case. It lies and misleads in the worst case. What do you do? You read the code.
Continue reading