Working Software

Ron Jeffries published a wonderful post titled “working software“. He quotes the agile manifesto “working software is the primary measure of progress”.

Now, he explains that what exactly “working software” means depends (as always). But in general,

Working software is real. It works. It can be tested. It can be verified. Questions about whether it does X are readily answered with “Yes” or “No”. The less ambiguity there is in our answers—our true answers—the closer to “working software” we are.

And he shares his opinion on “best development style”:

The best development style we know today, whether working solo, in pairs, or in a mob, is to pick a very small thing that the system doesn’t as yet do, verify that it doesn’t do it, then make it do that thing, verifying again, and keeping the code at or above our standard of internal quality.

How small should that thing be? Tiny. Smaller than that. No, smaller still.

I repeat that:

  1. pick a very small thing that the system doesn’t do yet
  2. verify it doesn’t do it (the “red” step in the TDD cycle)
  3. make it do that thing
  4. verify it does it (the “green” step in TDD)
  5. keeping the code at or above our quality standard (the “refactor” step in TDD).

I really like that. It’s not always that easy. But more often than not.

I know of TDD but I need to get better at remembering this (I’ll put that in my Anki deck) – including the very small part – and then practice it.

git push with force

Recently on our team chat: “I removed the remote git branch and pushed again”. “Remove” was not necessary, he could have used “git push –force” or better “git push –force-with-lease” instead.


The normal “git pushed” only works when the remote branch is contained in your local branch or in other words if your local branch is the same or ahead of the remote branch. When you still want to “overwrite” the remote branch with your local branch, use the “–force” option or the “–force-with-lease”.


When you collaborate with other team members on a remote branch, git push with force option may overwrite their work. “–force-with-lease” makes git check that the remote branch is in the state we expect it to be in before pushing the local branch, so you wouldn’t destroy work that you don’t know of.


We need to force push when

  • we changed our local branch history by rebasing or amanding
  • we need to “reset” the remote branch to our local branch


If you need to “overwrite” a remote branch with your local branch, use the “–force-with-lease” option.