Update: At the bottom of this post, I've linked to two large and quite different discussions of this post, both of which are worth reading...
Update 2: If the contents of this post make you angry, okay. It was written somewhat brashly. But, if the title alone makes you angry, and you decide this is an article about "Why Testing Code Sucks" without having read it, you've missed the point. Or I explained it badly :-)
Some things programmers say can be massive red flags. When I hear someone start advocating Test-Driven Development as the One True Programming Methodology, that's a red flag, and I start to assume you're either a shitty (or inexperienced) programmer, or some kind of Agile Testing Consultant (which normally implies the former).Testing is a tool for helping you, not for using to engage in a "more pious than thou" dick-swinging my Cucumber is bigger than yours idiocy. Testing is about giving you the developer useful and quick feedback about if you're on the right path, and if you've broken something, and for warning people who come after you if they've broken something. It's not an arcane methodology that somehow has some magical "making your code better" side-effect...
The whole concept of Test-Driven Development is hocus, and embracing it as your philosophy, criminal. Instead: Developer-Driven Testing. Give yourself and your coworkers useful tools for solving problems and supporting yourselves, rather than disappearing in to some testing hell where you're doing it a certain way because you're supposed to.
Have I had experience (and much value) out of sometimes writing tests for certain problem classes before writing any code? Yes. Changes to existing functionality are often a good candidate. Small and well-defined pieces of work, or little add-ons to already tested code are another.
Update: This is quite a long article. If you're looking for a quick read, it breaks down a bit like this:
Update 2: There are active and interesting discussions of this article on HackerNews and Reddit
I have a lot of love for Scrum, the software development process. I have my own little box of Index Cards and Sharpies, and I have sized Backlogs for many of my side projects. Scrum has potential to empower developers more than almost any other set of techniques.
But in almost every implementation of Scrum I've seen in The Real World™, managers are incentivized to help their team deliver broken software to a deadline, and usually end up succeeding in the former and failing in the latter. And when implemented like that, a system that should be an absolutely overwhelming win for developers becomes a tool to beat them around the head with...
So here's Scrum, simplified, and as it's meant to work: You have a Backlog of work to complete, broken down in to Stories, which are distinct pieces of work that should take a few hours to a few days to complete. These are frequently displayed on a Story Board, real or virtual.
Let's start with Gherkin. Gherkin is basically a constrained application of English meant for specifying test cases. For example, for a calculator you might write:
You then set up a number of step parsers that match the steps (called step definitions), and execute code based on it. eg:
Usefully estimating software projects is difficult, but not impossible.
A lack of understanding about why we estimate, what to estimate, and how to estimate leads to a breakdown of trust and communication between developers and managers.
Developers end up feeling guilty that they're not meeting their estimates, and at the same time defensive: they were just estimates after all, right? Managers feel exasperated that everything is taking three times as long as it should. What are they doing all day?
This article is about fixing your estimates, and your estimation process. It's split in to two parts - the part you're reading, titled "How to Estimate like an Adolescent", and the part you're not yet reading, titled "How to Estimate like an Adult - What to Steal from Agile".
As an aside, if you're in a position where someone else is estimating work you're doing, get out. The work will be late, you will be blamed, and you will be miserable. Programming is meant to be fun, and setting yourself up for accusations of professional incompetence and the niggling feeling that maybe you are incompetent is the antithesis of fun. Seriously, get out.
In Part 1, we talked about the primary problems with estimating software development accurately:
But we ended with the uplifting message, which is if you plan for the former (by multiplying out your estimates), and make sure you adequately track the latter, then your estimates - when taken in aggregate - will probably be ok. And by ok, I mean better than 90% of other developers.
But who wants to be a 10 percenter, when you can be a 1 percenter?
I also promised Agile was going to solve all your problems ever when it came to estimating. This may not have been 100% accurate. What we are going to do is look at a whole bunch of Good Ideas(TM) that the Agile folk stole, curated, and invented when it comes to estimation.
It turns out that we humans get a little weird about time. However much you believe "six hours" is "just an estimate", however much buy-in there is from the team about this, and however many times you've accepted that there's always hidden complexity, if a six hour task takes eighteen hours, everyone gets a little squirrely.
I have a coworker, Johnny, who is at least a little bit smarter than I am.
But Johnny has an (irritating) habit of always appearing a lot smarter than me, because Johnny remembers everything.
I often have to read something a few times before it sinks in, especially if the content is somewhat technical, where Johnny has read it once and remembered it all, and can answer all manner of questions about it. Combine this with my having the attention span of gnat, and there's a problem worth solving here.
This is of course a mixed blessing for Johnny, as people are quite happy to use him as a technical reference with a really good audio API, which hurts his productivity some. Also: I recently found out he's using the technique we'll be talking about to learn Japanese,
In this brief post, I'm going to introduce you to the concept of the Spacing Effect, give you an overview of how I'm using it to commit massive amounts of useful (to me) information to memory, and then give you a set of interesting links to further your research.
This is a series of articles discussing the best pieces of Scrum. The pieces you - as a developer or Project Manager - can steal and start using independently of a wider Scrum implementation. We'll discuss which bits of Scrum you can rip-off without drinking any of the Certified Agile Consultant Kool-Aid - in short, we'll be looking at how to do Scrum for small teams and startups.
Scrum is a business process, and like any business process, it sits between you and the work you need to get done. If it doesn't help you get that work done more effectively it's a big waste of time. Good developers, like everyone else, hate having their time wasted.
Scrum is often implemented by someone who went on a Scrum Master Certification (NOW 90% MORE AGILE™) once, and is attempting to implement it as a set of cargo-cult rituals in the wild hope it'll make everything better, and more Agile or something. Sometimes this'll be a Project Manager, and sometimes this'll be someone billing their consulting time as a Scrum Expert. Planning sessions become elaborate Arts and Crafts sessions with Post-Its and Sharpies, the Product Backlog becomes time sheets by any other name, and Velocity gets used as a personal productivity measure.
In short, in the wrong hands, Scrum becomes a tool for wasting developer time, and neatly tracking, graphing, and reporting the resulting drop-off in productivity.
This is a huge shame, because done right, Scrum protects and empowers developers. It pushes commercial and business considerations back in to the hands of the business and the customers, while placing implementation decisions back with the developers where it belongs.
This article is one of a series on Scrum, The Good Bits.
One of the central principles of "Scrum that doesn't suck" is to maximize useful communication. If you load too much process on top of that, you actively inhibit communication. In theory, daily standups are a communication tool. The general process of daily standups is pretty simple:
Developers and Project Managers find almost infinite ways to screw up this simple process, from treating Burndown as a measure of how hard people are working, to allowing deeply technical debate to break out in the middle of them while everyone else is standing around getting bored, to squabbling about if people are attending the meeting as Chickens or Pigs (seriously, people actually do this).
I'm going to talk about what I think are the two most useful types of communication you get from the daily standups, and the minimum viable process needed to accomplish these. Specifically, we're going to talk through:
Software development is full of surprises - often unpleasant ones. What turns an unpleasant surprise in to a truly nasty surprise is when it's too late to fix it or do anything about it.
or Backlogs, accountability & the look on a Product Owner's face when their New Feature pushes another Feature over the deadline
This article is one of a series on Scrum, The Good Bits.
Scrum has this habit of giving new names to old ideas - status meetings become Daily Standups, requirements become Stories, and the list of things you need to do becomes a Backlog. Every so often someone discovers this and decides it means Scrum is bullshit, and loses the baby as the bath water swirls away.
This is a shame, because Scrum has a whole bunch of good ideas. And some of the best ones - from a developer's perspective - come from the Backlog.
I've had an opportunity to be part of a team doing a lot of greenfield development on a new codebase at a client recently, and it's been a lot of fun. The client already has a codebase that's grown organically over a decade to meet the changing and complex needs of a highly successful company, and is in surprisingly good shape considering. Still: it's huge, incorporates several competing implementations of The One True Programming Style, the occasional flash of mad genius, and a lot of code that was written by very dedicated developers working very hard to make very tight deadlines.
The new codebase shares none of the constraints of the old one, and the team is keen to keep things as pristine as possible as long as possible. One of the best tools in our arsenal is the enforced code review. New code entering the codebase needs to have been reviewed, no exceptions - and the goal is that most of the team reviews each piece. So far it's working out spectacularly well.
LinkedIn tells me I've been working on teams that have tried to incorporate code reviews with varying degrees of success for almost 6 years now, sometimes in larger teams that were sat in the same office, sometimes in smaller ones that were internationally distributed, and sometimes when I've paid external developers to look at code I've been writing by myself for clients.
So, here's what seems to work:
Few people seem to enjoy code reviews. There's the mental effort of understanding what someone was trying to achieve, the cognitive load of understanding how a piece of the system you're not working on is meant to fit together, and it takes time away from the joyful process of actually programming.