TLDR: starting with the end goal in mind and working backwards from there is a great structure for the easily distracted
Test Driven Development (TDD) is a common thing for developers to talk about but in my experience it is not actually used very frequently. I’d like to point out some real advantages for ADHD brains in using TDD.
TDD is like a todo list that checks itself when you finish the task
The first step of TDD is to write a failing test. That test represents the feature that you are about to write. You run the test suite, and the test fails. Great! The next step is to implement the smallest feature so that the test passes. Then you refactor as best as you can and repeat until you have built everything!
Here’s the more formal definition from agile alliance
- write a “single” unit test describing an aspect of the program
- run the test, which should fail because the program lacks that feature
- write “just enough” code, the simplest possible, to make the test pass
- “refactor” the code until it conforms to the simplicity criteria
- repeat, “accumulating” unit tests over time
This feels like a lot to do in order to write some code, and I agree – it is. I can think of at least two strong benefits for ADHD brains that you should really consider.
It’s a framework that helps you find the ‘smallest thing I can do that moves the project forward’
By having a test that is failing, and a consistent cycle of write test – write feature – refactor it is easier to not get caught up in the thousands of things that need to be done. Decide to write the test, then your path is chosen until it’s green. Don’t burn all of your decision making power constantly reprioritizing features. This feels like a living TODO list that is in sync with your code. Having one fewer thing to check off (as much as I do love checking shit off!) means I can keep my eyes on the prize more of the time and task switch less of the time.
Each feature is split into 3 chunks, and those are easier to pomodoro.
Obviously this is hugely dependent on the type of development you are writing, but if the goal is to make one test pass, then that might be a 10 min, 60 min, or 1 day job. The goal of making ALL the tests pass is much bigger. When done right the scope of the new test is slightly outside the focus of the previous test and the amount of new work should also be small. This is equivalent to making smaller TODO items and checking them off more frequently. That keeps the feeling of momentum going and is also easier to schedule – since many of us have trouble with task switching.
The ‘3 chunks’ part comes into play when you’re setting short term goals. If you’re losing steam and know that the test chunk is up next then you might be able to muster up strength to push through that small section. Alternately you could take a break early knowing that the next refactor is going to take a bit. Having 3 modes to move between can break monotony and also allow scheduling flexibility. To make a comparison it often feels like regular development is one single task: finish jira ticket. That is hard because it is monolithic and it has no clear end in sight. If the ticket is not done there is no reward, and the only two choices are to stop working 😟 or keep working 😠. That’s all stick and no carrot.
It helps move some of the “last 10%” earlier into the project.
“Finishing” is a hard thing for many ADHD devs because if you were lucky enough to find something genuinely interesting along the way it is probably not going to reveal itself in “the last 10%” of the work. The interest is gone, so the motivation is gone, so either the code suffers or the amount of effort required to keep the train on the tracks is immense. I keep quoting “the last 10%” just because to me that really takes 50% of the time because it is no longer exciting and I’m suddenly finding EVERYTHING to be more important than writing tests / documentation / code cleanup. TDD moves all of the testing and most of the refactoring / code cleanup earlier into the process so that “the last 10%” often just feels anticlimactic – just banging out a few more features.
Downsides.
I can’t write this and pretend it’s all free storypoints. It takes time to get used to writing this way. It’s definitely slower to start, and it might make pairing with your teammates feel weird. Some styles of coding aren’t well suited for TDD (non-logical front end work feels like a good example.) Lastly it still requires executive function in order to know what the next test is to write. This isn’t all upside, but I’d say you should try it and see how it works for you. I’m not a TDD advocate, but I’m digging in more to see how I can make it work for me.