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.
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
- Microservices as an Evolutionary Architecture
- (20/01/2017) The video
Thanks to sketchingscrummaster.com
