Tim Ottinger's thoughts on Software Development.
I don't know if there is another name for this pattern, but I've been calling it "progressive admission" and using it for many years. It is a story splitting skill, related to the "walking skelton" AKA "tracer bullet" technique. Say you are about to build a program that reads from a message queue and processes messages. Start Closed The first stage is to build the end-to-end system (reader,…
This is a blog I wrote on ButUncleBob (the Object Mentor blog) in 2006, republished here verbatim because that blog is not always available and because it still matters. Sooner, Not Faster There is a widely-held myth (well, near-myth) that Agile software development is about "going faster". It's really not. Oh, you might go a little faster, but that's not what it's about. To go faster, one will…
WARNING: this is an AI generated article -- but that's on purpose. Without any priming or preparation, I asked a chatbot about sprints and tickets, and got this as an answer. The Question: My team wants us to split up all the features into tickets and assign them at sprint planning, so they all have enough work to do and know what they'll be working on. Is this a good system? The Answer: Usually,…
I published my first post on Sooner, not Faster in 2006 on Object Mentor's blog ("But Uncle Bob!" was the title), a wiki I was encouraged by Bob to use daily. Later this theme had been picked up by many people. Ryan expanded it to "Sooner, Safer, Smarter" and I appreciate that also. I've had years, decades in fact, to be working through what it means to deliver sooner and more often. I've been…
Companies often build their software development as a series of handoffs . Every handoff is a queue . Queues determine how long work waits . The busier the person receiving queued work is, the deeper the queue becomes , and the longer work waits to be served. A common mistake is to obsess over developer cycle time (ticket closure) and ignore the rest of the process. For flow reasons, it is better…
The Faros report on AI-assisted development has been rattling around in my head for a few days. The story it tells is a strange one: Teams are producing more code. More tasks are being completed. More pull requests are being created. And yet : waiting times are up, review times are up, lead times are up, incidents are up, and bugs are up. The picture shows a development process that's getting…
I've written repeatedly about the 7 Code Virtues, and they have been reliable guides for me, as well as a language for describing goodness in code. When I started applying this agentically, I realised that I may have been wrong about ordering (as I suspected all along) and adjusted to 'Working is prime, the rest are equal', and this has served me well. The agentic code still wasn't going as well…
There is a commonly shown drawing, which came from a great Kniberg post (of course), explaining how every iteration in an agile development method produces something usable, and the capability of it grows over time. Rather than building parts to assemble later, as typically is done in function decomposition and bottom-up building. I reproduced the image here, to introduce the topic better. Of…
If you're curious how your pipeline and its pass rates affect your team's regular work, check out the Pipeline Gates Calculator . It's just a toy, but it may be enlightening. For each of your quality gates, enter the name of the gate, about how many minutes it takes to operate that quality gate (maybe automated tests run in 5 minutes, or manual test in 60*16 minutes), and the pass rate. Name --…
I believe in people. People are amazingly strange creatures. They walk this ridge between depression and anxiety, and walk it with joy. The world need to be stable enough that they can grow competence and skill. When it's too stable then they become bored and depressed, because it's all easily within their skillset and there is no growth or learning; they've been there and done that. When things…
Aint No Plannin' I see a lot of "agile" teams and their "planning" meetings, but if you forgive me for saying so, I've not seen a planning meeting for a long time. Typically: No plan is presented No questions about the plan are surfaced No revisions to a plan are made What actually happens then? Usually, someone loads up a list of tasks, and the entire meeting is spent assigning people to the…
Some time ago, on a social media platform, during a discussion about technology, a pundit posted a piece arguing that teamwork was a horrible idea. The Compromise Theory: His thesis is that an individual can have a great idea. When other people get involved, they have differing ideas. To settle the differences, the group has to make compromises. Every compromise is a degradation of the original…
The riskiness of a release is proportionate to the number of potentially untested paths in the new code. If there are a thousand new possible paths and we've only tested 4, then it's a significant risk to the installed base. If there are two, and we've tested both, then it's not risky at all. The larger a release (the more stockpiled functionality) and the less complete the characterisation via…
People are making a big deal about the new way of agentic working: Spec-Driven!!! But, wait... Big Design Up Front (BDUF) is something we tried for many years, in many companies, many times. It was proven to be a losing proposition and a bad idea. We did it in the 80s, and by 96 or so we had alternatives. If the idea of spec-driven is to fully detail a system up-front, and then use agents to…
This is one of those things that just doesn't stick in my head, so I'm dropping this note to remind myself. I often have trouble recalling cryptic variable names in bash, make, and perl. For my own sake, I thought I'd make a quick list of favorites and refer some sources. Maybe you'll find this useful too. Variable value, but exit if no such variable: ${var:?"error message"} Use default if…
A bit of background: I was chatting with some colleagues and friends this week about AI-augmented workflows. M was talking about having LLMs "write the epics and features" for teams. He was envisioning a flow where a PO or PM would have much less cognitive effort and could do this work alone and then hand it off to the teams for execution. Of course, the teams are using LLMs to help with testing…
You're working with some Python code, and would like to write a test, but... "I can't test that - it uses STDOUT!" Okay, well, that's really not such a big problem to handle. The solutions to this problem are actually simple enough that you can apply them to many other situations that might otherwise encourage you to skip tests just this one time (again). In our modern age, we have the advantage…
Sometime back in my early days of programming, I learned to enjoy a truth table. Fizzbuzz seems to beg for a simple truth table - the values ' should_fizz ', and ' should_buzz ' form up a simple tuple of booleans, and the choices are True, False - fizz False, True - buzz True, True - fizzbuzz False, False - string of the number This expresses rather neatly in Python, is efficient and pythonic, and…
Here is a .vimrc file built from the recommendations in my Vim book, " Use Vim Like A Pro " (available on LeanPub ). " =================================================================== " Basic .vimrc Configuration " Based on recommendations from "Use Vim Like a Pro" " Copy this to ~/.vimrc to use " =================================================================== " Turn on all the magic,…
Recommended bash scripts for every project clean_start ensures you are ready to start new work. It does: 'pull -r' (which fails if you have uncommitted work) a refresh of the local environment 'git clean -i' in case you have untracked files you've forgotten about a full test run. onboard is the script to run if you are a brand-new developer and you need to set up your development environment. It…
Working faster isn't working? Do you want to understand why that is? Warning If you are working with development teams (and aren't a developer or ex-developer) then this might be jarring , but it's intended for good and not for offense. The reason it takes so long for work to be done? I know from a distance it seems like it's "they're not working hard enough," but it's very possible (better than…
This is probably too snarky, but bear with me: If I fill my fuel tank with non-fuel or the wrong fuel, it will damage my car and fail to perform. Is that because fueling the car is a bad idea? If fueling a car is a good idea, shouldn't there be a million ways to do it so that it's easy for people? This "petrol only" rule = is too restrictive to be useful in the real world. Every time I put diesel…
i will submit that the problem of scale is mostly that you Have to deal with divergent, incompatible SW development paths Might not be able to handle losing fine-grained control of every element of the business. Are likely to accumulate heavy processes with a lot of inherent delay and unpredictability in them. Have to deal with "the law of the 2nd floor" (LO2F) The Law of Two Floors The first few…
I'm Tim Ottinger. You may already know me. I'm a long-time developer, agilist, XPer, CI/CD, teaming/ensemble, TDD, and general software delivery specialist. I wrote the second chapter of Clean Code . I am the originator and co-author of Agile in a Flash with Jeff Langr, and I wrote Use VIM Like a Pro . I'm mentioned in the "acknowledgements" sections of many other books on Code Craft, Agility,…
How much failure demand and rework do you feel is appropriate in your system? Rework in software is the correction of unacceptable code. That doesn't include refactoring, which corrects only the design and expression of ideas without changing what the code does. This is limited to "something does not work correctly and we can't let it be released." So, we don't want any of that, right? It delays…