Course:
TDD for C++
Date entered:
2018-11-29 21:55:18 UTC
Course rating:
Good
Most useful learnings:
The outline of the TDD strategy, and a few trials of using it.
Concepts v exercises:
Good balance
Presentation v discussion:
Good balance
Course improvements:
Run the exercises just like TDD: one step at a time. Allow only 5 to 7 minutes for each step. Evaluate and correct immediately. An exercise that takes a one-hour block is "batch coding" that allows for too many errors, getting stuck, learning bad habits, etc. 18 students is too many when not co-located.
Exercise rating:
Fair
Exercise improvements:
I don't use an IDE (IntegratedDevelopmentEnvironment), but I do use two text windows: source on the left, compiler on the right. Then I can see the error message and the source at the same time. This is extremely important. Flipping back and forth is painful.
First day: If we're supposed to ignore some C++ class, then don't put it in!
I found it really hard to figure out where to start, and to recover from initial bad start. Hearing directions once during the last 40 seconds, accompanied by the instructor scrolling and flipping through several files just before starting, left me lost.
Instructor comments:
The joke about the changing the word 'friend' in the term "C++ friend class" was in poor taste.
Better prepared:
A little
Start tomorrow:
No. Pre-scheduled other activities: quarterly review, planning for next quarter, travel to "all hands planning session".
Challenges to applying:
Geographic (and time-zone, and work-hour) dispersal encourages silo-ing. Getting a pair of developers in the same place at the same time is almost impossible.
Adopting TDD will take longer in the beginning.
Given a choice "We can deliver a new feature that is MVP [officially "Minimum Viable Product", but in reality "Minimum Sellable Product"] in 3 months, or the same feature but which can be realistically and profitably maintained in 6 months", then 9 times out of 10 management will choose shorter-time-to-market regardless of expected profitability. This is not _entirely_ irrational! First-mover advantage is real. The Board of Directors may be choosing the destination or direction for the company; the CEO may be "driving"; but the VP of Sales is "riding shotgun" and "navigating". (The VP of Engineering is in the back seat.) Synergistic feedback from early adopting customers can work well, but is hard for a non-startup company.
Other comments:
The #define macros that expand to two or more CHECK actions have incorrect style. A macro call that feels like a function call must BE a function call. In particular, there must be a semicolon (emphasized here with white space):
#define THEN_NO_LIGHTS_CHANGED \
CHECK(LightControllerSpy::NONE == lightSpy.getLastState()) ; \
CHECK(LightControllerSpy::NONE == lightSpy.getLastId())
If necessary then use "do ( ... ); while (0)" so that syntax encapsulation works.
TDD throws away 1/3 of the valuable results: namely, what was implemented to cause each accidentally-passing test to FAIL. Recording those is essential to a retrospective which looks at whether TDD is being done properly, and to looking for systematic weaknesses in the application of TDD. Also, twice the strategy "Implement the least production code which causes the formerly-failing test to PASS" caused cascading work in subsequent steps, which meant re-doing work, including re-creating failures!
Legacy code workshop:
No
Recommend to others:
Only if improved
Quote permission:
No