Highlights from Smartly.io DevTalks — Tackling Complexity in Software and Teams
In November 2017, we hosted the first ever Smartly.io DevTalks and brought together 80 experienced engineers from the Helsinki tech scene. Discussion revolved around complexity in software and engineering teams and how to fight it. Speakers included MPJ from Fun Fun Function, Sami Honkanen from Boss Level Podcast, and our own VP of Engineering Otto Hilska. Big thanks to all visitors and speakers!
Smartly.io is growing fast, and scaling doesn’t come without its challenges. Tackling complexity is a topical theme for us, and the external speakers at DevTalks were hand-picked by Smartly.io engineers to cover interesting viewpoints on the topic. In fact, about 40 percent of the DevTalks audience was our own software engineers, data scientists, and web developers.
Maximizing learning and sharing knowledge transparently are key components of how we work at Smartly.io. DevTalks combined these two aspects of our culture: our engineering team learned a good deal, and we got to share our learning experience with the wider tech community. The event was a success, and we’re already getting ready for round two later this spring (stay tuned). Here’s a quick recap on the highlights from the keynotes by MPJ and Sami Honkonen.
Surviving death by complexity — a call to arms against software bloat by MPJ
The first speaker of the evening was MPJ, who runs Fun Fun Function, a YouTube channel about programming, which some of our engineers follow regularly. He has a solid 13-years experience as a developer for companies like Spotify, Absolute Vodka and Blackberry. The topic of his keynote was software complexity.
Over time, software tends to become slower and more difficult to use — a condition called software bloat. It’s particularly common in software that lacks neither funding nor pairs of hands working on it, and it essentially emerges from functionality. MPJ’s talk detailed certain measures software engineers can take to manage the influx of functionality.
One way to manage software bloat is removing functionality that isn’t in much use. Killing features is, unfortunately, ungrateful work and takes a lot of planning to get right. People don’t usually go through the trouble, even when it is in the best interest of the software and 99% of people who either use or develop it. MPJ has first-hand experience from killing his darlings: pushing to remove redundant functionality, he ended up with a net-negative of code during his time at Spotify.
Alternatively, you can choose not to put in a lot of functionality in the first place, producing a minimalistic product. Or you can sandbox different functionalities, isolating them from each other in a way that makes adding new ones and killing or adjusting outdated ones easier and less risky. The best way to deal with software bloat depends on how your software is built, what it does and it ought to do. There’s no one-size-fits-all solution.
One way or another, software complexity has to be managed. If bloat isn’t taken into consideration, a sort of natural selection occurs: the software stagnates and gets replaced by leaner software made by competitors. As MPJ said, it’s the software engineer’s job to manage complexity and reduce bloat.
Some of our engineers’ favorite videos at Fun Fun Function:
Responsive organizations — adding just enough structure to avoid slipping into chaos
With the next talk of the evening, we moved from complexity in software to that lurking in organizational structure. Sami Honkonen, CEO of Tomorrow Labs and host of Boss Level Podcast, introduced us to responsive organizations and what they’re made of.
Responsive organizations thrive in complexity and uncertainty, because of their ability to adapt to a quickly changing environment. The key word is experimenting: as soon as the environment becomes truly complex, experimenting is the only way to find out what works. Being data driven is also a must for healthy responsive organizations, especially in making decisions based on actual data instead of gut feeling.
Systems thinking is another building block of responsive organizations. It’s about seeing the big picture and relationships between the different parts of the organization. Systems thinking focuses on improving the whole, not optimizing locally, and looks at everything from the customers’ perspective.
Finally, responsive organizations need people on the field who are cleared for making decisions and taking action. Two key questions behind designing responsive organizations are: What is the least amount of structure your organisation can have without slipping into chaos? How can you make the structure you need as lightweight as possible?
Dive deeper into the topic with these podcasts at Boss Level:
DevTalks will be back
We were humbled to get amazingly good feedback from the first ever DevTalks, and would like to thank all of you who joined us. We’re excited to get the show on the road again this spring and see what we could learn together this time!
Learn how we have approached tackling complexity in our Engineering team in this blog post by our VP of Engineering, Otto Hilska: How Engineers Work at Smartly.io.
Originally published at www.smartly.io.
