IDD

Okay, so, you've heard of Test Driven Development, where tests (unit, functional, system, integration, and contract) are written first, then the code that passes the tests is written to that test's specifications, as a way to write good, efficient, tested code.

There are also Acceptance test-driven development (ATDD), behavior-driven development (BDD), example-driven development (EDD) and story test-driven development (SDD) styles of code writing. I'm most familiar with the last.

We have (mostly because I wanted) a tech-debt sprint every 4th sprint on my main project at work. These are sprints where we do not introduce new features, but rather fix bugs, improve infrastructure, increase performance, or refactor that write-once-to-learn-copy-once-and-shit-copy-again code into a don't repeat yourself (DRY) bit of code. When feature development is blocked, for whatever reason, we continue developing, but the priority order is often unclear.

Until today.

Katherine commented she was doing Irritation Driven Development (IDD) and I love the term. "These things bug the F out of me, I am going to fix this" seems a great way to bring joy back into a project and code. I am delighted.