MongoDB.local In Auckland is done and dusted for 2023, and to call it an outrageous success would almost be an understatement.
With great power comes great responsibility, and we, as software engineers, have an increasing, and probably disproportionate, influence over the success and failure of the organisations we represent and serve.
With that comes enormous opportunity and responsibility.
Our decisions as engineers and as engineering leaders have the potential to be business-critical, and through the zerospam story (a business I founded in 2006), I was able to share how a critical database failure resulted in a thriving business going out of business within three short days.
We should always assume that our decisions are long-term unless we are 100% sure that we know otherwise.
You don't always know when an idea or system will take off. When we designed and built zerospam, we designed and built it based on what we expected the customer base to be. However, growth exceeded this, and e-mail velocity and volume vastly exceeded this.
Changing engineering decisions on systems that are running at scale is like changing a flat tyre on a vehicle travelling at 100 kilometres per hour on the motorway. It's almost impossible and almost never happens. What inevitably happens is that those engineering decisions become massive anchors that create drag and slow the business down.
Long-term decisions require careful consideration, and it was interesting that in a follow-up conversation with an experienced engineer over lunch, he commented that the more experienced he became, the more cautious he became in his decision-making because he realised the significance and the impact that those decisions would have on his organisation.
Decisions, particularly around our tech stack, have the potential to radically affect the agility of our teams, engineering functions, and entire organisations.
They can equip us with the tooling to disrupt markets or serve as anchors that create massive drag and slow us down, increasing our delivery cost and ultimately giving our competitors an advantage they didn't even ask for.
The key takeaway from my presentation yesterday was that we, as engineers, are deeply responsible not only for the success and failure of our systems but, at times, the success and failure of the businesses and organisations we serve.
When a building collapses and people are injured or killed, we expect the engineers who designed and built that building to answer some very serious questions.
I also spoke about some practical steps we've implemented at Cloudize to ensure this type of failure will not occur in our business.
Composition has always been part of good software design. However, as we abstract our level of composition and start designing engineering solutions by composing capabilities from reliable, robust, secure and dependable cloud technologies, we find ourselves in a wonderful position to reduce our area of focus and expertise to that which is core to our business - the thing our customers genuinely care about - the reason that our businesses exist and what our customers pay us for.
Inevitably, your customers will indirectly care about several things. These are not the things you should be building; instead, they should present an opportunity for you to partner with organisations that have made delivering those capabilities their primary reason for existence.
In closing, we want to thank MongoDB for offering us the opportunity to share our story and look forward to seeing you at the next one.