The technical implications of Continuous Delivery permeate every aspect of the way we write code.

Whatever makes it into the release branch, we must have high confidence that it works.

So we must see it pass all the tests before we commit any changes... If our tests are slow, this will be impractical. So our tests need to run fast.

For our tests to run fast, our code will need to be easy to unit test.

Easily unit-tested code needs clean separation of concerns. It needs to be highly modular...

"I think stand-ups are useful because it's the only time our junior engineers get to talk to the senior engineers." I think you may be proving my point. Me: "Why don't the senior engineers pair with the juniors?"

"Because they need to get some work done"

Hmmm. And what are the junior engineers doing while the senior engineers are "getting some work done?"

A new thread: I'm gonna tell you some war stories about agility and unit tests (1/n)

https://twitter.com/jasongorman/status/1251408890505420800

A year before "Agile" became a brand, I worked on a banking project with multiple dev teams. One team wrote unit tests for all their production code. That team quickly earned a reputation for reliably delivering, which earned trust, which improved collaboration with the biz (2/n)

"No Code" is predicated on the notion that software development = writing code, but your average developer spends a tiny fraction of their time doing that. It also denies the obvious: it's not code, it's *logic* that non-programmers find difficult at any level of abstraction We've been here before. The key benefit of allowing end users to create their own apps is putting problem & solution in the same brain. But that brain *will* need training. They'll need to *think* like programmers. And that takes a long time. Cue a shortage of No Code app gurus.

It's still got a while to run, but when I compare the emerging results of this poll

https://twitter.com/codemanship/status/1214907604406820864

with this poll

https://twitter.com/codemanship/status/1214561232750923776

, the picture seems to conflict strongly This is an example of a wider phenomenon. Teams say "We do X" (where X is CI, or TDD, or refactoring, or BDD etc), and a lot of the time they very simply just don't. Alarmingly, they often don't know what X even is, which is why they don't know they're not doing X.

"We didn't think of that combination of inputs"
"We didn't foresee users clicking the 'submit" button twice"
"We didn't account for balances too big to fit in an int"
"We didn't envisage two processes accessing the same data in that order" My reply: "What thought did you put into exploring the possibilities?" Did they do a truth table or a decision table? Did they sketch a state transition model or a response matrix? Did they use Venn diagrams to explore the entire input space? Did they visuallse concurrency?

Fast-running developer tests (or "unit tests") are essential to making code changes easy and safe. When devs tell you to ditch them in favour of slower-running high-level (API, customer, system etc) tests... well, all can say is I've seen that go badly wrong many times. (1/) The typical justification given for ditching unit tests is that they make refactoring harder. This tends to only be true when we forget to refactor the unit test code, or when the imlementation design has serious dependency issues, and/or when we over-rely on mock objects (2/)

Lots of people asking about Evil FizzBuzz. So here are the instructions: (1/) First, this is intended as an exercise in combining TDD with Continuous Integration (i.e, Continuous Delivery - not breaking the build!) (2/)

You might think, as our profession expands exponentially, that the highest priority would be to keep the most experienced devs at the code face to mentor the ever-growing numbers of people entering the industry... But, as a trainer, I've seen just how few companies invest in their younger devs skills, and as a job seeker just how keen the industry is to move me out of code-facing roles into mgmt (because of my age, basically)