Course:
TDD for Embedded C
Date entered:
2019-08-14 19:19:32 UTC
Course rating:
Excellent
Most useful learnings:
I learned a new superpower. If there is one thing I am allowed to change in a software development project, then it is the use of TDD. All the other things like clean design, high-quality code and higher productiviy follows from the application of TDD. Thank you, James, for teaching this superpower to me.
Concepts v exercises:
Good balance
Presentation v discussion:
Good balance
Course improvements:
Maybe a tiny thing. I would have loved to have an exercise on getting legacy code under TDD on the third day. But that's probably the content for another course.
Exercise rating:
Excellent
Exercise improvements:
I got stuck on the full and empty condition of the circular buffer for quite some time. I had to go back to the last green revision several times. I thought afterwards that a hint about the condition could have been helpful. The exercise was not about circular buffers but about learning TDD. My second thought was that this was an excellent lesson for me: Let TDD guide me to the solution and never resort to bad practises (trial-and-error, printf's, copying a solution, etc.). It was hard learned but valuable.
Instructor comments:
James was there, when the Big Bang of TDD, XP and Scrum happened. He has incredibly deep and broad insight into TDD and loves to pass on this knowledge. I especially enjoyed his reviews of my exercise solutions. James let me participate in his thinking. He has a good reason and explanation for every small step and decision. Even when James was not there, the exercises felt like pair programming with him.
Better prepared:
Bring it on!
Start tomorrow:
Actually, I will start tomorrow. I will have to add some inportant features to the legacy code base of my customer. The customer "didn't have time" to test their code. The course eliminated the last tiny doubts in the back of my head to use TDD. I am sure that I'll only be able to succeed with TDD.
My other project is a library for the CAN communication between a user terminal and ECUs in vehicles. I have a lot of unit tests and a mock for the CAN bus in place, but I didn't do rigorous TDD so far. Thanks to the course, I know how to improve the tests and how to move on with TDD.
Challenges to applying:
I am a solo consultant. Many of my customers (SMBs) think that testing will slow them down. At the end of the project, one customer said that it would have taken them twice the time with testing. My answer was: "My team used rigorous unit testing right from the beginning. That's why we are the only team delivering on time." The other teams used a trial-and-error approach and easily spent 80% on debugging. Despite the facts, the customer didn't change his view on unit testing.
Other comments:
The remote delivery worked surprisingly well. Attendees could ask questions or add comments by chat, in the parking lot and by audio as a last resort. The remote setting kept discussions on a well-tempered level. No one was able to hog attention. There were not stupid remarks. This format could be a chance for more introvert people.
When doing the exercises, James was always around for questions and reviews. A one-on-one session could easily be extended to a session for everyone, when a problem or solution were interesting for the whole group.
Legacy code workshop:
No
Recommend to others:
Yes
Quote permission:
Yes