Listen

Description

Chapter 8 - Pragmatic Projects

Season 2 - Episode 13 - Chapter 8 Part 1

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.

60 - Organize teams around functionality


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.

61 - Don't use manual procedures


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.


62 - Test early. Test often. Test automatically


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.

63 - Coding ain't done till all the tests run


'Nuff said


JP: Keeping your feature branch green!

John: ALL the tests - unit, integration, performance, staging, usability, QA

64 - Use saboteurs to test your testing


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

JP: Husky on NPM

John: Hound - It's a service