At Tragic, we have been building web-based software for a long time. We have seen it evolve, change, and grow in purpose, experience, process, and underlying architecture. There have been a number of new programming languages and frameworks, and a fair share of fads along the way as well.
Most importantly, we have seen a giant shift in the way that software is developed.
How Software Used to be Built
In the early years of web and mobile applications, the launch was a HUGE deal. There was huge momentum, grueling nights of development, and lots of pressure to finish everything for the launch.
Every feature, style, and experience had to be perfect – and in its completed form.
At that time, nothing changed. When you launched your website or product, it sat in that state until it was replaced with a new fresh version. Sure there were some small bug fixes, minor tweaks, and security updates but those happened to support the software that was launched and not to grow or change it.
Launch announcements were a huge deal, and a rocky product launch was egg on the face and in some cases could really damage your brand severely.
But then something happened… We got user data.
The use of marketing and product analytics was a game changer. Companies suddenly had insights into what worked, what did not, and why their product was resonating with users. And, crucially, they had the ability to change their products for the better.
"If we have data, let's look at data. If all we have are opinions, let's go with mine." –Jim Barksdale, former Netscape CEO
Instead of shoving every single feature at first, product managers and software development teams have taken a more iterative approach to building products. This viewpoint has been advanced, in part, due to the rise of lean software development. The lean principles are:
- Eliminate waste
- Amplify learning
- Decide as late as possible
- Deliver as fast as possible
- Empower the team
- Build integrity in
- Optimize the whole
Modern Software Development
Modern software is built iteratively. Sometimes the changes to the software are large, sometimes they are small but they are always happening. Tech companies constantly segment and test new features on portions of their audiences, and even launches of new features or services happen in waves.
It is no longer about the launch, it is about the growth.
At Tragic, we believe in iterative growth and incremental refactoring. We advise all of our clients to start small, test, analyze, adapt, and grow.
Launching every feature at launch is expensive and ill-advised. When you are launching a new product you have very minimal data, so you don't want to make all of your decisions effectively putting all of your eggs in your launch.
Start with the smallest product you can afford based on your launch goals, gather feedback, and start the iterative process. You can grow features, functionality, and your addressable audience over time.
Another mistake we see is running before learning how to walk. Once you start your post-launch releases, you can’t always run forward at full steam. Features need to adapt, interfaces need to grow, code needs to be reworked. Not every release can be a new feature release, sometimes you need to refactor and sometimes you need to support new operating systems or devices.
The cadence of refactoring depends on the age of your codebase, and how much it has changed over the years.
Tech debt must always be repaid. It's easier to do it slowly over time as you are progressing forward, rather than have it creep up and cause massive hours of repayment all at once. We encourage you to incrementally refactor your product, code, and interface to keep the codebase stable and ready to pivot.
When to Rebuild & Refactor
Sometimes your product hits a wall of tech debt that is just too high to overcome. When new clients bring us existing software to support, we don't push them to rebuild or replatform unless it is necessary.
- We only push for a complete ground-up refactor:
- When the product is on an archaic (or no) framework
- When the framework is heavily manhandled with raw SQL queries and other extreme bad practice code
- When the client wants to make a major pivot that the current codebase would be too much technical debt to invest in an incremental refactor
Many business stakeholders believe that technical debt isn't real or isn't a priority. Unfortunately, this mistake comes from optimizing over the short term (weeks) instead of looking at the length of the average software project (months to develop and years of ongoing support).
The goal should be to deliver value to customers, and that requires understanding their needs incredibly well and continuing to improve your product. We have seen firsthand how building the right foundation and processes can save months of time, hundreds of thousands of dollars, and countless headaches.
Are you looking to improve your software development practices? Tragic Media has 10+ years of experience, building everything from MVPs for startups to enterprise-grade business applications. Get a free consultation today.
