Thoughts from a Thirsty Bear

Test Driven Development. "TDD". Some love it, some hate it. But many studies now suggest that it is highly effective in reducing bugs (some studies suggest up to 90% of bugs can be eliminated) and improving code structure. But how does it work? Why is there such an effect from such a simple approach?  But before I start I must point out that a lot of what follows is summarising a great talk by Keith Braithwaite called " Measure for Measure: quantifying the effect of TDD " from 2008.  This is just a distillation of his somewhat mathematical analysis and conclusions, simplified, and in my own words aimed at a new audience who may have missed this particular gem. So our story starts with complexity. Cyclometric complexity to be precise. Cyclometric complexity simply explained is a measure of the number of paths through a piece of code. So it depends on the number of decision points - if, while, and switch statements etc. The more paths, the more complex the code is, an...

"A little learning is a dang'rous thing; Drink deep or taste not the Pierian spring: There shallow drafts intoxicate the brain, And drinking largely sobers us again" - from " An Essay on Criticism, Part II ", Alexander Pope Those who know me, or have read my profile online, know that I teach teams how to develop software using iterative tools and techniques. These require rewiring some of the traditional, waterfall-style thinking and approaches, and yes, they can be a culture shock. In order to warn my trainees I always go through a specific explanation with them. It kind of goes like this: Many folks expect learning to be straight line. You do a training course, or read a book for something, then you use it.  Unfortunately this is the South Park Underpants Gnomes model of learning. It leaves out the important part. Learning does not work in a straight line. It's messy. It's unpredictable. You will make mistakes. Go down blind intellectual alleys. Get co...

  Ah meetings. The bane of all our lives. Some are useful, others...less so. But the perception has always been that they get in the way of doing our real jobs. Yet they are a necessary evil - used well, they allow information to flow between people and allow discussion to happen. Before I go on, I should point out that no, this is not another article about how to make your meetings run better, how to write a better agenda (you  are  all creating an agenda for your meetings, aren't you?) and so on. Enough has been written about that already. What I'd like to share today is a calendar hack that I find useful to tame that most annoying and insidious habit to become widespread since we have gone online -  back to back online meetings . Since 2020, when Covid forced us into the most extensive remote working experiment ever, I have noticed a trend throughout industry to book meetings into every slot, one after another. Days like that are exhausting, and people have to dis...

As developers, we should all know how to write a good git checkin message. Done right, it makes delving into change histories delightful rather than a chore.  What's that? You have never been told how to write a good checkin message? Chris Beam's article is just the thing for you!  (Chris explains the rules far better than I could here without going off on a tangent) TL;DR: Separate subject from body with a blank line Limit the subject line to 50 characters Capitalize the subject line Do not end the subject line with a period Use the imperative mood in the subject line Wrap the body at 72 characters Use the body to explain what and why vs. how But I want to talk about Rule #2 (with a little about Rule #6 thrown in). That 50 character first line limit. Rule 2. Limit the subject line to 50 characters Back in the Dark Ages, when monitors were typically 80 characters wide, this limit made some physical sense. You didn't want to wrap commit summaries because it makes them scra...

A term that I still hear occasionally is "SDET", or "Software Development Engineer in Test". It is also known by a few other terms - Developer in Test, Test Automation Engineer and so on. Essentially it is a job role for a developer whose main responsibilities are to write automated tests and frameworks to check software. And it is a truly awful case of missing the point completely . It is a job title that indicates a fundamental systemic problem in an organisation. First, some history. Back in the Bad Old Days of the 1900s, we used to develop software using a linear waterfall style process, mostly due to a bizarre and tragic misunderstanding of a single academic paper (Royce, 1970). There was a lot of management thinking that modelled software development as a factory production line, and assumed that there were cost reductions from specialisms - someone creates a software design, someone builds that design, and someone tests what has been written. At the end, som...

  We all know tests need to be reliable (don't we?!). One of the worst things any test can do is give false results, whether consistently or intermittently. A test that passes when it should fail gives a false sense of security. A test that fails when everything is OK leads to wild goose chases trying to find the non-existent problem. This should be obvious. We call these false positive and false negative  results.  But just recently I have been thinking about  what is a false positive and a false negative?  It's obvious - until it isn't. So hopefully writing this down will clear it up in my mind, and some others. I'll add that this is my thinking right now after discussing the issue with several people - just make sure the definition inside your own company is consistent. Turns out, whether something is a positive or negative, false or otherwise, depends entirely on what signal is being detected . What is the 'positive' signal?  For testing, what is a tes...