The Software Ark: Issue 10
Quote of the week
If I had asked the public what they wanted, they would have said a faster horse.
- Henry Ford
Articles
Software Engineering best-practices
I was reading this article on software engineering practices, and it got me thinking what are some of the things I think lead to the best software, and what rules do I follow for myself to build good software. This article on outperforming a 10x developer is also a good source of ideas.
What comes to my mind when it comes to best-practices includes:
- Documentation-driven development. Much like TDD, DDD starts with doing something other than coding first, in this case, writing documentation. The idea being that writing forces precision. For more complex systems, having a general idea of what the components are, their responsibilities, etc. ahead-of-time can help clarify the problem space without needing to write any code. I don't always follow it, but if something is complicated enough, it tends to be my go-to approach to writing code. I stole this from Al Vermeulen who wrote critical parts of S3 back in the day, and attributed its clarity to this approach (in a tech-talk). He wasn't wrong.
- Not being protective about ideas. A good idea is a good idea - doesn't matter who it came from, or who's executing on it. If someone else comes up with a ebtter idea, it doesn't diminish me, and I've got to become comfortable with trashing my idea and instead following theirs. If I come up with a good idea, it's perfectly fine for someone else to execute. Focusing on where we need to go, and not how exactly we get there (as long as you're making forward progress) has helped keep me humble and learning.
- Having a minimum quality bar. All code that's pushed out needs to have at minimum: some public documentation, some unit-tests (80+% coverage), critical metrics (availability, latency, error-rates), critical logs, a readme for devs to get started, and ideally some canaries to tell you if it goes down. If you have time you can add-in some end-to-end tests, and if you're lacking time you can defer certain things e.g. internal documentation can be a bit sloppy, or a readme may be sketched out but lacking details. But it all has to get done before the feature is considered complete. We used to have an unspoken rule at Amazon: that every service (including internal ones) had to have an availability of 4 9's. That mindset forced quality, and sometimes even that fell short.
- Having a good relationship with stakeholders / representatives. Writing quality code takes time, and sometimes it might be the wrong call. You may need to get to market (shipping is a feature, one you can't live without) and that may mean writing sub-par code. But having that relationship with stakeholders allows you to understand the lay of the land, advocate for quality, for investment in tech-debt, for focus, for prioritization.
- Advocating for the customer. This is not the same as "the customer is right", nor is it about doing exactly what the customer wants. Instead it's about knowing what your customer needs, their jobs to get done, which may not be what they ask for (see quote about faster horse). Then you got build it for them. It's about trying to delight them every chance you get. And if that comes at the cost of the system's architecture or code cleanliness (within limits) - then better your system than the end-customer.
Ultimately, what's also helped has been an acknowledgement that what I know about software development is very limited. A sincere belief that I'm an idiot that just happened to get lucky has helped me internalize that "there's almost always a better way".
This youtube series about the time China hacked Google is fascinating. That nation-states are targeting enterprises (and individuals, with MBS targeting Jeff Besos a while back) is taken for granted today, but it wasn't always this way. This is why I think WhatsApp focus on encryption is the right call, and zero-knowledge security the right long-term direction. That said, as we build out platform teams and platform support, we need to make sure that we build for security from day 1. We have to assume for a defend against bad-actors. It's only a matter of time.
Links
- Facts about state-machines, who doesn't like them
- I've wanted CFn to have Fn::ToJsonString for a long time - I just didn't know it yet
- Meta's Horizon Worlds is apparently not good, but it might be the future
- CSS to look good everywhere - where was this when I was building my blog?
- Do I need to be worried about this kind of identity theft?
- Why some feedback hurts and what to do about it?
- A good list of free-ish diagramming tools - my 2c, always choose a tool that supports diagrams as code.
- What makes a great manager, also a good read: the coach and the fixer
- Function over form - let me do what I want and get out of my way. This is why I'm not a fan of Apple devices.
- WTF - a cross DB SQL tool - I love it!
- Stadia died - noone trusts Google - it was great tech, but I can't disagree.
- Fundamentals of Control Theory (book)
- You can't just Google things, you need to remember them
- Building a platform: jobs to be done
Your moment of Zen
Who doesn't want smart flip-flops. Selling a 100$ flip-flop for better ad targeting feels like the sort of thing that probably should be illegal.
