On Twitter I…
…made a toot-storm about using construction as a metaphor for software engineering.
I've never really got on with construction metaphors for software. The cost of mistakes and rework is high in construction
This isn't saying that Software isn't putting things together but rather I've seen people justify not 'being agile' by using construction metaphors.
Experimenting with a "new" retro format
For our team's most recent retro we decided to try a new format to see how it affected our discussion. We thought we'd share it here in case it has value for other teams.
What is it?
A retrospective is a practice from XP described on the c2.wiki as
A practice which has an XP team asking itself, at the end of each iteration : What went well ? What could be improved ? What could we experiment with ?
We've recently had several discussions trying to focus on the real and perceived progress of our work and thought it would be beneficial to run the retro with a focus on the impact of our team's principles and practices. Specifically how they relate to delivery of value and speed of delivery.
Where we're going we don't need columns
A few years ago while waiting for a user group to start at the Manchester ThoughtWorks office I bothered a couple of the devs there about their board. That conversation, after a bit of fangling, led to my convincing the team I was on at the time to use a radar board to represent our backlog.
It allowed us to combine a fluid representation of the business's priorities with a physical representation of the cost of reorganising those priorities. But also, in a way you don't get with a columnar board, gave an immediate feedback mechanism when too much work had been proposed or accepted.
Apologies to the two ThoughtWorks devs if I misrepresent any of their good ideas as mine or my bad ideas as theirs.
Big Pile of Soil
During Kevin Rutherford's guided discussion on clean code at Agile Manchester 2017 we talked briefly about whether there was a difference between 'cleaning code' and 'clean code'.
I suggested that I might expect to have to make code dirtier on the road to making it cleaner. Being of the opinion that sometimes you need to add duplication in order to see your way to removing it.
As I am a creature of bad habit I jumped immediately into tortuous metaphor.
Generating static AMP pages
AMP or Accelerated Mobile Pages is a Google-backed project that allows you to use restricted HTML to delivery static content quickly. Since AMP HTML is restricted it isn't a fit for every site.
Since this blog is published as static HTML articles it is a good candidate for publishing an AMP version. An open source AMP jekyll plugin was amended to add AMP versions of pages.
The major discovery was that the validation tooling around AMP is awesome. Compare that to Facebook Instant Articles where there is basically no validation tooling (that I could discover at least)…
This didn't feel like a topic that justified several posts so to avoid taking too long this is a bit of a whistle-stop tour of adding AMP pages to this blog.
Yarn is a new JS package manager that promises to be fast, secure, and reliable. My initial experience is that it is fast and easy to use. I'm excited about making time to use it for real at work. Kudos to the developers!
Adding Structured Data to a Jekyll site
Structured Data is a way of adding context to files served on the web so that computers (primarily but not only search engines) can respond to what your content means.
Google, for example, will alter and improve how your site appears in search results based on the context you give your data. And if your site is considered authoritative can use the data to build the knowledge cards it sits alongside other search results.
This blog is only authoritative for being unread but I've not worked with structured data and thought I'd investigate.
Using Travis CI to build a Jekyll site
I recently had a conversation where I said that I couldn't build an AMP version of my blog because I use Github Pages to build and serve it. Github don't allow any Jekyll plugins to run.
Later that day my subconscious prompted me to realise that, since Github pages will serve static HTML quite happily, I could use Travis CI to build a Github repository that held the source for the blog and push the static output to a second repository that Github would publish as is.