For instance, I think the kanban concept is more basic than estimation. That is, teams that keep starting new work without finishing the old work are working very hard but get very little ‘done’. Thus you have some limit on how many tickets can be open. I know a very well run cafe where that’s the main management practice they use, only taking orders when they are running low on work in progress.

My beef with estimation is that the model that ‘task A has N subtasks and you can estimate the individual subtasks and add them up’ (which works well in a certain sense) is often less correct with the model that ‘the developer sends a work unit to the tester which may or not be sent back to the developer’… in which case the most important factor for how long it takes to do work is how many times you send it off to the tester.

Sometimes I dream about working with a ‘tester’ in a much more closely coupled way than I do. I always have to ‘test’ something myself to convince myself it works to avoid the embarrassment of sending something to the tester that is 100% busted. I frequently spend a huge amount of time setting up tools and environments for testing. That includes the traditional unit testing (which runs quickly) but also processes like building a full text search index for a system with a few million records, testing to see that a machine learning model builds automatically and works properly, that a full text search engine gives relevant results, or spending four hours building a database so I can run interactive queries against it.

If somebody was helping out on that kind of stuff and could test stuff I do with a turnaround of minutes instead of ‘fill out a lot of paperwork and wait 2 days to 2 weeks’ I’d spend more time thinking and coding. (W/ the caveat that thinking about testing can lead to a better design more often than it leads to Test Driven Design Deformation.)