“Building something for change will allow it to last the test of time.” – Emmanuel Iroanya
A common obstacle in software development is building a product that can keep up with the constant shift of standards, frameworks, and languages within the tech industry.
What does it take to make your product resilient through these changes over time?
We spoke with Emmanuel Iroanya, Founder and CEO of theta, about the importance of software resilience. He shares common pitfalls developers make when crafting their applications, explains why teams should build their own software frameworks, and makes the case for building software that adapts to new standards (instead of trying to last).
In this interview, we cover:
- What it means to “build for change”
- How to adopt the mindset of building software for change
- How to make an existing piece of software agnostic
- When to choose an existing framework vs. building one
The conversation below has been edited for length and content.
What does it mean to “build for change, not to last?”
Building for change means you should build your systems to be agnostic, so your software is versatile and adaptable to new standards.
If your application doesn’t gel with new specifications, you end up churning. You’ll have to constantly change your application to keep it alive within the newest standards.
If you build your application as agnostically as possible, you’ll only have to add a couple hundred lines of code to make it function within these new parameters. That’s preferrable to spending ample development time to keep your application running when a change happens five years down the line.
Building something for change allows it to last the test of time.
It frees you to move forward.
How do you adopt the mindset of building software for change?
A lot of teams use existing frameworks rather than building them.
But how much of those frameworks are actually used?
You probably went in there for four or five specific things, but now you’ve brought a lot of bloat within your application because your heart was set on using the entire framework.
Instead, start by building. If you build your framework, you’ll reduce that bloat and will have more control over the portability of your software.
If you find an existing framework that is useful for what you need to do, then replicate the individual pieces that are needed and strip out what’s unnecessary.
Any developer who embraces that mindset will make software tools that are strong building blocks for resilient applications.
How do you make an existing piece of software more agnostic?
If your software doesn’t easily adapt to new standards you’ll need to retrace your steps.
Ask yourself a few key questions:
- What decisions did I make to get to this point?
- What choices caused me to inherit these problems?
Once you have evaluated your decisions, identify where you can refactor any poor decisions or how you can start ripping out individual pieces of the framework.
The result?
You’ll gain control over your software and help your application acclimate to change.
When should engineers use an existing framework over building one?
At times, it makes more sense to use a framework that you’re already familiar with in the front-end. For example, there are plenty of front-end languages (like Angular and JavaScript) that are designed to adapt.
The problem is when back-end frameworks do all the heavy lifting for things that aren’t even heavy to begin with.
If you’re building your application to be modular, with small services that perform different tasks, then it’s probably better to build your own framework. If you try to adapt existing frameworks to work in ways that they weren’t originally intended for, you will inherit a lot of problems for no reason.
Don’t get trapped by a framework.
Successful engineering teams don’t build software that operates at this moment in time. They build software that’s built for change. That’s resilient software design.
