This week we talk about organizing teams around functionality, why you shouldn't use manual procedures, why you should test early, test often, test automatically and using saboteurs to test your testing.
John: Welcome to Iteration: A weekly podcast about programming, development, and
design through the lens of amazing books, chapter-by-chapter.
JP: This is part 1 of Chapter 8
John: This chapter is all about "Pragmatic Projects" - Teams, Automation, Testing, Documentation Code quality and more.
Don't separate designers from coders, testers from data modelers. Build teams the way you would build code.
JP: It's a mistake to think that the activities of a project - analysis, design, coding, and testing - can happen in isolation. i.e. Offers V2 at OL. Leaders of a team: needs at least 1 technical and 1 administrative personnel. Always think of the business goals
John: It's nice to have lots of full stack devs - They can focus more on a "Module" than a specific tech or "side" of the project.
At the dawn of the age of automobiles, the instructions for starting a Model-T Ford were more than two pages long. With modern cars, you just turn the key—the starting procedure is automatic and foolproof.
John: We are developers! Why would we do ANY tedious work? Example: Github's API pulls in PR's and notes.
A shell script or batch file will execute the same instructions, in the same order, time after time
JP: "We may have to build the starter and fuel injector from scratch, but once it's done, we can just turn the key from then on" i.e. deploys
Let the computer do the repetitious, the mundane—it will do a better job of it than we would.
Tests that run with every build are much more effective than test plans that sit on the shelf.
JP: In the Smalltalk world, they say, "Code a little, test a little" -> Get those small wins and make incremental changes
John: Write tests to help guide design.
'Nuff said
JP: Keeping your feature branch green!
John: ALL the tests - unit, integration, performance, staging, usability, QA
Introduce bugs on purpose in a separate copy of the source to verify that testing will catch them.
JP: After you have written a test to find a particular bug, cause the bug on purpose to make sure the test complains
John: Code coverage analysis tools are very helpful
Picks