"Semantic Diffusion" is everywhere and why this matters...

a #Thread
1/19 I have been lucky in my career to have been close to the birth of several ideas that later became extremely popular, my overriding impression is that if you asked any creator of a popular idea, the commonest reaction would be "That's not what I meant at all!"
2/19

How do we protect the systems that we create, fundamentally I think that this falls into the common pattern of there being two strategies, and as is often the case, one of them is dumb.
#Thread

1/13 We can either work in terror of changing them, with change freezes and change approval boards and lots of bureaucratic checks and balances,
or we can do the agile thing, and embrace change.
2/ 13

Continuous Delivery specifically and Agile development in general is primarily about optimising our work so that we can make progress in small steps, and so better understanding our progress after each small step,
but what does this mean for Software Architecture?
1/14

#Thread Some descriptions of Software Architecture describe it as the "stuff that we can't afford to get wrong"

I think that this is a big mistake, because if we can't afford to get it wrong, it means that we MUST GET IT RIGHT FIRST TIME, and the chances of that are slim.
2/14

I recently talked about User Stories on my YouTube channel, and got asked by several people about how I would deal with "Back End Stories", so here is a thread User stories for "Back End" vs User stories for "Front End"
a #Thread

1/14 My problem in answering this is that I don't make that distinction. The idea of a User Story is significantly different to that. User stories have somehow been subverted, like much of agile thinking, by people looking at them from the perspective of project management.
2/14

I think that Continuous Integration, and the disciplines that it forces on us to achieve it, is probably the most profound idea in SW dev practice.
So here's a #Thread to explain why I think that this is about much more than semantics or personal preference.
1/15 I have said many times that feature branching in particular is incompatible with Continuous Integration. That is because both of the words in CI matter, we integrate continuously - or a close approximation of continuously.
2/15

What is the best way to design software?
Top Down, or Bottom Up?
#Thread

1/15 This is a fairly old idea in thinking about software design, and I confess that I find the terminology a bit confusing, particularly if you read the Wikipedia definition:

2/15en.wikipedia.org/wiki/Bottom–up…

Dealing with "Coupling" is one of the things that makes SW a genuinely difficult activity. But I think Coupling is at least as big a deal for SW dev teams as it is for the software itself.

Here's a #Thread

1/14 Coupling is an interesting idea, and there are many dimensions to it. I particularly like the @mtnygard model of coupling described in this video, and have been quoting it for years.

2/14

Agile isn't dead, but it is widely misunderstood and more unusual than most people think.
a #Thread

1/12 I have spent the vast majority of my career working in what today we'd call 'agile' teams and organisations, but I hadn't heard the term until 20 odd years ago.

2/12

Microservices are maybe not what you think they are, so here's a #Thread to describe them...

1/14 Microservices are distinct from Services, although they are commonly confused.
Services, as an approach to software design, have been around for many decades. Service Oriented design was popular in the 1990s and early 2000s.

2/14

What is the most important thing that I have learned in my career as a software developer?

Here's a #Thread

1/18 We could consider languages, how computers work, OS commands, understanding of design techniques and tools like editors and IDEs.
We could think of the need to collaborate, reducing dependencies & coupling, and focus on outcomes, but there's something more important.
2/18

I confess that I am not a big fan of "The Test Pyramid" so here's a #Thread on what I think is a better focus for your automated testing strategy...

1/14 The Test Pyramid is usually described as something like this, though there are lots of different versions.
I don't think this helps much.

2/14

In this tweet @christofebert says "optimising for velocity is dangerous" in software development. The article that he references is behind a paywall, so I haven't read it, but here are some thoughts, and some evidence that counters this view.

(A thread)
1/17

https://twitter.com/christofebert/status/1614299044532178944

As ever it depends on what you measure, what does "optimising for velocity" mean?
Velocity is speed + direction. In software terms, I assume that we mean that speed is the rate at which we can deliver software.

2/17

My recipe for Continuous Delivery (a thread)...

1/14 Start by measuring your Cycle Time, from "idea" to "working software in the hands of users"

2/14

Unit Testing or Acceptance Testing?
Actually you need both for the best test-strategy.

a thread...
1/12 I think that the right answer is "Both!" because each delivers different things, and provides very different insights and advantages for the systems that we build.
A good testing strategy needs both kinds of test.
2/12

One of the few things that I can be absolutely definitive about is the definition of a "Deployment Pipeline", because I defined it. So here is a short thread that answers the question “What is a Deployment Pipeline".

1/9 Defines Releasability

The DP is an automated mechanism to determine the releasability of changes. It should be definitive for release. If the pipeline passes there is no more work to do prior to release.

2/9

A few thoughts on the properties of good automated tests
(Hint TDD encourages these properties more than after-the-code-unit testing):

A Thread.
1/9 Understandable
Tests should shout out what it is that they are testing and asserting.
2/9

Here are a few thoughts on things I wish I knew when I was first a tech lead...

a thread

1/7 The Leader's Role is to Help the Team be the Best they Can Be.

It's not really about having the best technical skills, but rather about amplifying the capabilities of the team as a whole.

2/7

TOP 5 TIPS FOR TDD

Last night's video reminded me that there are a lot of good developers out there still making simple mistakes when it comes to #TDD.

Below are my tips for success and why it WILL work for you.

A THREAD 🧵🪡

#SoftwareDevelopment #SoftwareEngineering 1) Always start with a test.

Writing the test first shapes your design for the better. Starting with a test will set you up to code in an attempt to pass your test, rather than continuously going back to fix code that's tested too late, and failing.

Start as you mean to go on.