#AgileAfrica Keynote: Why does yesterday’s best practice become today’s anti-pattern?

Posted: September 12, 2016 in Technical
Tags: ,

This is a post in a series on the talks that I attended at my first ever Agile Africa Conference in Johannesburg. All posts are based on the sketch-notes that I took in the sessions. 

I was hoping the video for this talk would be available before I got round to blogging about it, however unfortunately it isn’t 🙂 I’ll update this post with a link once it is available, because I don’t feel my notes will really do the talk by Neal Ford full justice.

agileafrica

The talk kicked off with a couple of tales about QWERTY keyboards and the legacy that remains. Most people have heard of the fable that QWERTY keys are arranged to help typists type more slowly to prevent jamming (apparently not true…), however how many of us have ever considered the underscore? Sure, we use it now, because it’s there, but did it  really make sense to port if over to modern-day keyboards when it was originally there to enable manual typists to underline pieces of text? Perhaps not 🙂

To Neal, anti-patterns are wolf ideas in sheep’s clothing: they are ideas that look like a good idea at the time, but sometimes turn out to be a terrible idea. He then went on to describe six practices that have potentially proven to create anti-patterns over time:

1. Abstraction Distraction

Abstraction seemed like a clever idea to black box certain functions, however as the abstraction layers increase, things become increasingly complicated and confusing, eventually resulting in so much abstraction that the code is almost unusable and people are afraid to go in and make changes because they have no idea what will break

2. Code Reuse Abuse

Code reuse in principle, is good, but it can also lead to a whole bunch of dependencies that need to be managed.

3. Overlooking Dynamic Equilibrium

Things change all the time – and they change at different paces – so it’s really hard to plan an architecture for the future because you don’t know which parts will change when and at what pace. It’s no longer possible to be predictable, so rather focus on being adaptable.

4. Dogma

“Do it because I said so” or “do it because that’s how it’s always been done”

5. Sabotage
  • Cowboy coding
  • Focusing on cool stuff rather than necessary stuff
  • Inventing cool puzzles to solve
6. Forgetting that some things scale non-linearly
  • Examples are code, teams, and tools over time.
  • As the size increases, the pain increases exponentially
  • Tools have life-cycles and Neal recommended that when you are using a tool and it starts becoming painful to use, the you should probably start looking for a new tool

Neal also recommended a book called “Evolutionary Architectures” and mentioned some key concepts to bear in mind:

  • Components are deployed
  • Features are released
  • Allow for incremental change at an architectural level
  • Embrace experimentation and remember to include users in your feedback loop

And I’ll leave you with one last thought from the talk: Is Transitive Dependency Management tomorrow’s GoTo anti-pattern?

LINKS
nealford2

Thanks to sketchingscrummaster.com

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s