Tinned Fruit Missives January 2017
Welcome to the very first edition of Tinned Fruit Missives!
You’re receiving this email because you agreed to let me send you occasional newsletters like this one. Each edition will contain a handful of links to interesting articles about front-end web product engineering that I’ve come across over the last few weeks. There’s no publishing schedule, but I hope to send one every month or so.
I won’t be sending too many links about the latest hot JavaScript framework or nifty CSS animation techniques. Instead, I hope to focus on topics such as front-end engineering practices, growing teams, and long-term technical strategy. I hope you enjoy it!
As this is a bit of an experiment, I’d love to get some feedback on what you think - just reply to this message to dump your thoughts on me.
Without further delay, let’s get on with this edition’s links…
– Jim
Toward a Galvanizing Definition of Technical Debt - Michael Feathers
michaelfeathers.silvrback.com/toward-a-galvanizing-definition-of-technical-debt
Anyone who has worked with me for a while knows that I regularly invoke Michael Feathers’ work when talking about legacy code and technical debt. Like many software engineering practices, his approach to transforming legacy code is not well known in front-end engineering circles, which is a shame. Increasingly the front-end is where the pains of product and technical debt are most keenly felt.
In this article, Michael proposes a less rigid definition of technical debt as the refactoring effort needed to add a feature non-invasively. This definition recasts technical debt as a flavour of product debt, which makes it a problem for more people to think about. Instead of casting refactoring work as fixing past technical mistakes, it is more positive and persuasive to present it as work that enables future product improvements.
What we learnt from our mistakes in 2016 - Gareth Trufitt, Guardian Developer Blog
www.theguardian.com/info/developer-blog/2016/dec/18/what-we-learnt-from-our-mistakes-in-2016
It’s refreshing to see a team honestly and publicly ‘fess up to their mistakes. Many companies claim to do this without publicly going in to much detail when things go wrong. In this post, Gareth Trufitt talks about some of the bad deploys that The Guardian team made in the last year. I chuckled when reading this because some of these are eerily familiar to my own past experiences.
It’s worth noting that all the examples in the article were impacted by front-end tooling or client-side performance concerns. More complex front-end tooling means more opportunity for problems in production code, so it’s important to have appropriate client-side monitoring and testing in place.
Even if you don’t release public incident reports, it’s valuable to set up an internal process for this that includes a description of the problem, the lessons learned, and most importantly, the actions that will prevent it happening again.
Hype Driven Development - Marek Kirejczyk
blog.daftcode.pl/hype-driven-development-3469fc2e9b22
This has a slightly clickbait-y title, but it’s a healthy and amusing reminder to focus on our own situation and context when choosing technical tools like frameworks and libraries, and avoid the hype around the Latest Big Thing. Front-end engineering is particularly prone to this because it’s moving so quickly and there is still a huge opportunity for better tools.
The advice at the end is useful - do your own testing and research and hire people that are technically adept at fundamentals. I would have also added that it’s important not to bet the farm on an immature technology. Sometimes it’s important to choose boring technology, especially if you don’t have Big Company Resources that can afford to swallow expensive mistakes.
