Agile is associated with speed. The promise of Agile is working code faster, but how does this happen in practice? Though practices like Test-driven Development (TDD,) Continuous Integration (CI) and Continuous Deployment (CD.)
These are easier to understand when you see them in action, so imagine you’re standing over the shoulder of a web programmer, who’s building blog software. They start by writing the “write blog post” screen, and then they load up their browser to see it. Something’s not quite right, the post button is in the wrong place. So they go back to their HTML editor, make a fix, then check the browser again, hitting the refresh button. Ah, that’s better. Now they go back to their HTML editor and add some PHP code so it connects to the database and saves the post. They go back to their browser, try it, then they check the database to see if the blog post really got stored. Nope, it missed some data. So back to the PHP code to find the bug… and this back and forth continues until that screen works properly.
If you’re lost by this example, there’s an analog. Imagine writing a long document, but whenever you want to re-read anything you just typed, you’ve got to print it. That’s a lot of waiting for the printer. Same thing with coding.
It’s like writing a document with the proof-reader standing over your shoulder giving instant feedback when you need it.
Instead of manually testing on the staging server, we can automatically release code that passes all of our prior tests. This is called Continuous Integration. For example, if our blog programmer starts writing a complicated new feature but accidentally breaks old functionality, the old traffic light will turn red and point it out to them right away. Since they know they just created the bug, they know where it is and can address it quickly. If it were later caught on a staging server, it wouldn’t be fresh in the programmer’s mind so it would take a lot of time finding the bug.
I’m a new parent, and prioritising my attention on our new rhythms as a family.
Work-wise, I’m trekking along at a cozy pace, doing stuff that doesn’t require meetings :)
I have a few non-exec/advisory roles for engineering edu programs. I’m also having fun making a few apps, going deep with zero-knowledge cryptography, and have learned to be a pretty good LLM prompt engineer.
In the past, I've designed peer-learning programs for Oxford, UCL, Techstars, Microsoft Ventures, The Royal Academy Of Engineering, and Kernel, careering from startups to humanitech and engineering. I also played a role in starting the Lean Startup methodology, and the European startup ecosystem. You can read about this here.
Don't miss The Floop (2024)
Some kind of parent (2024)
Retreats for remote teams (2023)
What do you need right now? (2023)
Choose happiness (2021)
Emotional Vocabulary (2020)
Project portfolios (2020)
The history Of Lean Startup (2016)
Entrepreneurship is craft (2014)