Changes in software development are accelerating, notes Magnolia’s CTO Jan Haderka, who has been developing software since 1995, and has lived and worked through the trends of the last years. In this episode of the DX Talk, he looks at agility as the way to navigate those changes.
Subscribe to Magnolia's DX Talk on iTunes: https://itunes.apple.com/ch/podcast/the-dx-talk/id1374875874?l=en&mt=2
“If you look back 10-15 years, we lacked the optimization, and building the base for systems of complexity like a CMS took a long time,” says Haderka. “Nowadays, with more computing power and with moving a lot of development and compilation steps into the cloud, things happen faster and people find that they don’t have so much time to think about the things they are doing.”
Curiously, developers themselves were among the last ones to benefit from these advances in technology. Haderka explains: “We were able to develop sophisticated tools 10-15 years ago, if you look at something like Adobe Photoshop or Word and Excel. Those were end-user tools done by developers, but not really for developers. Only in the last years have developers benefited from advanced ideas and usability patterns. We now have more tooling that helps us solve problems: better debugging tools, better code completion tools, fast-to-build tools and tooling that lowers the barriers for people to get started.
“It’s great on the one hand, because software development is now open to more people. On the other hand, very often people then jump into developing software without actually knowing or considering the complexity of the stuff they are going to do. They need to discover the complexities, the fact that there are still plenty of algorithms and patterns, the soft software engineering knowledge that is necessary in order to make the right choices and develop the software correctly.”
More agility and flexibility
While not a zealot of agile development, Haderka supports the move to more agility and flexibility. He says: “Instead of coming up with the big plan and then watching this plan fall behind, we look at the solution we’re supposed to deliver and break it down into smaller pieces. We set ourselves some baseline, like defining the minimum viable product, defining the different phases in which we develop the fixes, knowing where the cut-off line is and reconciling it with the time we have invested in development.
“What’s makes it more difficult is that managers need to learn to live with uncertainty. You don’t have a plan that is carved in stone, given and followed no matter what. You need to more dynamically think about what’s happening, how you are moving, how you need to re-negotiate on what kind of features you are delivering, or timeline, more people and teams, because the project is more complex than expected.
“However, it’s a natural part of business acceleration. Consumers want changes fast. Retailers with e-shops want features delivered faster, so they can sell more. That puts pressure on software companies, and by proxy on software developers, to do things faster. And because we have to do things faster, agile is the only way to do it. We have to be able to move quickly, or more fluidly, without being too rigid or too stucked into what we originally agreed on doing. Today, requirements change daily. You develop something to show the prospect or customer. They look at it and come back immediately with feedback or some other twist to the original requirement that needs changing. It’s the agility that gives you the flexibility to push to change the solution, to keep going.”
This demands agility from developers as well. While computer science graduates in the past might be prepared to stick with certain programming languages and tools in the course of their career, they need today to constantly evaluate different tools and watch the frontier of software development because “tools are popping up like mushrooms after the rain”, as Haderka points out.
He says: “As we shorten the development cycle and put developers closer to clients, they need to understand the use case of the customer much better, in order to be able to develop. The business owner, the customer, is always part of the team and is the one approving that the job is done as specified. They give immediate feedback to developers, so developers are actually learning the rules of the business from them. This ensures that what is being developed is actually useful for the customer and not just another tool.”
Haderka has this advice for developers working in the realm of constant change: “Just never stop learning. Be open to new ideas and listen to people around. Be ready to admit that you don’t know everything and that others might have better perspectives on the things that you are trying to achieve. The problems we are solving in software engineering are not unique. They have been solved elsewhere before, maybe in simpler ways. Now we’re just using different tools, looking at the problems from different angles, making it better.”