A: You factor out a bit of common functionality from your project code, and compose a cute little function that does just that. The API into your function is simple, your inputs are well-defined, and the output is deterministically decided by your inputs. You know exactly when it is correct; so you compose a suite of unit-tests to prove its’ correctness and add that to your continuous build/test process. Very nice. Have some coffee.
B: Your management has mandated that you shall be always as one with the Test-Driven-Development (TDD) buzzword. Everything you write, is unfinished until you also write the unit-tests, lots of them, and everything passes. No sweat – TDD has proven benefits, you say. Predictability. Reliance upon correct software. Every sprint (a term from the SCRUM process) has milestones, and tests to prove them. But those tests are no small amount of added work. And with each incremental bit of functionality, many existing tests now fail. So you have to go back and fix those. More late nights of coding. The frig empties of creamer. Oh, by the way — now some of your teammate’s code is failing. Oops. Well – they gotta get on board with the new functionality you just added – so they’re working late too. The show-and-tell is tomorrow. Maybe it will work – who knows? Everyone has been so buried in trying to meet the milestone, that no-one has had a spare moment to sit back and really see whether this project is going in a good direction.
What happened? How did you ever get from A to B? And is your job (and your company) still going to be around tomorrow — will you survive?
Let’s talk about this. and I’ll continue this story next week (check in Monday morning, 4/22).