In software development, there's a saying that I've come to appreciate:
It's never about technology - until it is.
It's a bit of a riddle, a paradox that seems to contradict itself. But as you dwell deeper into the world of code, systems, and digital solutions, you'll find that this statement holds a profound truth.
Let's break it down.
When we say, 'It's never about technology' we're acknowledging that at the heart of every software solution, every app, and every digital tool, we're trying to solve a human problem. We're not just writing code for the sake of writing code. We're creating solutions to make people's lives easier, to streamline processes, to bring joy, or to connect people. Technology is not the end goal; it's the means to an end.
But then we say, 'until it is'. This is where the paradox comes in. While our ultimate goal is to solve human problems, we can't ignore the technology itself. The tools we use, the systems we design, the code we write - they all matter. They're the vehicle that carries our solutions from concept to reality. And if that vehicle isn't built well, it won't get us where we need to go.
Let's look at two real-world examples. First, take Klarna, a Swedish fintech company, that had a simple idea: bring trust to e-commerce by providing a buy-now-pay-later service. (I wrote more about the Klarna installment plans project separately.) This idea wasn't about technology; it was about solving a problem. Merchants worried about getting paid, and customers worried about receiving what they ordered. Klarna's solution addressed both concerns in a very simple way: include a paper invoice in the delivery.
As Klarna grew they needed to handle an increasing number of transactions, maintain a robust service and deliver features quickly. That's where technology came into play. Fortunately, Klarna had chosen Erlang as the main technology for their online payment system.
Erlang allowed Klarna to rapidly prototype and test new features, thanks to its functional programming paradigm. It also provided robustness and scalability, critical for a company handling billions in payments. Klarna's success story isn't just about a great business idea; it's also about choosing the right technology to execute that idea.
Our other example is WhatsApp. It wasn't about groundbreaking technology; it was about providing a simple, reliable, and user-friendly platform for people to connect. And connect they did, in the billions!
WhatsApp had also wisely chosen Erlang to implement its secure messaging service. Erlang was the unsung hero, working tirelessly behind the scenes to ensure that every 'hello', every 'happy birthday', and every 'I love you' was delivered without a hitch. It allowed WhatsApp to manage billions of messages with a relatively small team of engineers, a feat that was nothing short of miraculous.
Erlang's functional programming paradigm allowed WhatsApp to rapidly prototype and test new features. It also provided the robustness and scalability needed to handle an ever-growing number of messages. WhatsApp's success story isn't just about a great business idea; it's also about choosing the right technology to execute that idea.
Let's not forget the unsung heroes - the people. People are the lifeblood of any organization. They are the ones who breathe life into technology, turning cold, hard code into vibrant, dynamic solutions. At HappiHacking, we're all about people. We believe that the right people, armed with the right tools, can create magic. And by magic, we mean robust, scalable, and efficient solutions that drive business growth.
But here's the challenge - how do we strike the perfect balance? How do we ensure that our focus on people doesn't overshadow the importance of business value or the role of technology? This is where we need a guiding principle, a compass to navigate the delicate balance between these crucial elements.
That is where the Happy Path Method idea comes in. It is a way to keep the work anchored in the path that proves value first. The point is not optimism. The point is to avoid spending all the early time on imagined branches before the team has tested the main flow.
The name sounds lighter than the work. In practice it means understanding what success looks like for the business, then building the smallest serious version of that path so the team can learn from a real system.
It is easy to get lost in technical details and potential edge cases. Those details matter, but they need context. A working core flow gives that context. It shows which risks are real, which assumptions were wrong, and which pieces need stronger boundaries.
This approach does not ignore potential problems or challenges. Instead, it acknowledges them but does not allow them to derail the development process. It's about maintaining a positive, solution-oriented mindset. It's about saying, 'Yes, we will likely encounter challenges along the way, but let's not allow those challenges to distract us from our primary goal.'
In consulting work, this usually means starting with the client need, the operational constraint, and the system boundary. Then we choose the next technical move that makes the situation clearer.
When it comes to technology our go-to tool is Erlang. If we can not use Erlang, we are also well-versed in most other programming languages, and we can take the Erlang philosophy with us to any environment.
Erlang comes with a set of tools and principles that make it easier to build robust, scalable, and maintainable applications. One of these principles is the idea of supervisors and independent processes.
In Erlang, a supervisor is a process that monitors other processes, known as worker processes. If a worker process encounters an error and crashes, the supervisor automatically restarts it. This means that even if a part of your system fails, the rest of it can continue to function normally. It's like having a safety net that catches you when you fall, allowing you to get back up and continue on your path.
This ties back to the same habit. When the core path is clear, the failure cases become easier to place. Supervisors help keep local failures local, so the system can recover without turning one bad process into a wider outage.
Moreover, Erlang's support for independent processes means that different parts of your system can operate concurrently and independently. If one process encounters an issue, it doesn't affect the others. This means you can continue delivering value through the other parts of your system, even when facing challenges.
In essence, Erlang and OTP support this style of work because they make boundaries explicit. You can build the path that matters, observe it, and then strengthen the surrounding failure handling with the runtime instead of hiding it in convention.
As for our services at HappiHacking, we're not just about coding. We're about creating solutions. We're about understanding your business needs and translating them into technology. We're about leveraging our expertise in Erlang, Elixir, Java, testing, DevOps, and other technologies to deliver solutions that are tailor-made for your business. From system architecture and design, to development and code reviews, we've got you covered. We're not just service providers; we're your partners in growth.
The next time you think about technology, remember - it's not just about the code. It's about the people who make the code work. It's about the methods that make the journey enjoyable.
So, yes, it's never technology - until it is. We must always remember the human problems we're solving, but we can't ignore the technology that helps us solve them. It's a delicate balance, a dance between two seemingly opposing forces. But when we get it right, when we find that sweet spot between problem and solution, between human and technology, that's when we create something truly remarkable.
When it comes to choosing a technology partner who understands your needs and delivers solutions that drive growth. Choose wisely, choose HappiHacking!
