Agile development and minimum features set are great for getting continuous customer feedback, rapid iteration, and avoiding wasted code. However, if developers aren’t careful, code written to attract early customers can become unwieldy, difficult to maintain, and incapable of scaling over time. Ironically, this becomes the opposite of agile. And, the bigger the company’s success, the worse the problem becomes. The logical solution is to re-architect and re-write the product.
But, for a company in a rapidly changing market, this is usually the beginning of the end. A technical founder turned chairman of a company discussed a problem with his friend. The company was growing, but it became less and less responsive to the changing market and customer needs. The company’s revenue was good, but it could go out of business in two years if it can’t keep up with the customers’ rapid shifts in platforms. The CEO, who lacked a technology background, was frustrated that he couldn’t get the new features and platforms he wanted, like Facebook, iPhone, and Android, because the code had accumulated a lot of technical debt. The VP of engineering explained that the only way to deliver these changes was to re-write the product. The board thought it was a good idea.
The code base, which had now grown large, still had vestiges of the original exploratory code written back in the early days when the company was in the discovery phase of Customer Development. Engineering designs made back then with the aim of figuring out the product were not the right designs for the company’s current task of expanding to new platforms.
The CEO and VP of Engineering were confusing cause and effect. Customers aren’t asking for new codes. They are asking for new features and platforms—now. Customers don’t care whether it was delivered via spaghetti code, alien spacecraft, or a completely new product. While the code rewrite is going on, competitors who aren’t obsessed with architectural purity will be adding features, platforms, customers, and market share. The difference between being able to add them now versus a year or more in the future might be the difference between growing revenue and going out of business.
Perhaps the most dangerous side-effect of embarking on a code rewrite is that the decision condemns the old code before a viable alternative exists. Who is going to want to work on the old code with all its problems when the VP of Engineering and CEO have declared the new code to be the future of the company? The old code is as good as dead the moment management introduces the word “rewrite.” As a consequence, the CEO has no fallback. If the VP of Engineering’s schedule ends up taking four years instead of one year, there is no way to make incremental progress on the new features during that time.
A Treacherous Road To A Software Development
I believe in building complete solutions for my clients, from ideation to launch. A full development process comes with pros and cons. Most product builds are time-consuming and complicated.
Many of our customers have climbed hard roads – and at Smartly Built, we are here to help and make that path easier! Our team is dedicated to helping you build your idea into a smart application with a great experience that solves everyday problems for your users.
It’s an iterative process where we partner together and collaborate closely as we design the prototype, include all your feedback, and work on building the final product! We also support you with launching your product to market when it is ready.
Our mission is to make your dreams a reality. Not just to help design and build but also to launch and gain traction in the market. We can do many things well, and building customized complete solutions is the expertise we are most proud of. If you are an enterprise, small business, or startup – we are making your growth climb easier.
We enjoy building digital products as we get to delight our customers by being a one-stop shop for their needs.
5 Ways to Optimize Data Performance
What good is a well-designed user interface if your data does not load properly or quickly? Performance is often great when your data is local – but saving data locally is not ideal for most solutions. We see significant challenges when data is grabbed from multiple sources and presented to your users. It’s like picking up food from 5 restaurants to serve your party, instead of 1. Not very efficient and increases the risk for issues and errors!
Did you know there are specialized things you can do to solve this and optimize your performance?
From data conditioning to synthesizing, building a technology stack that reduces your performance bottleneck, to engineering your API and data infrastructure.
I am going to share 5 ways we can help you optimize your data performance.
The top things you can do includes:
- Engineer your data collection well so you are not fetching data from everywhere.
- Fulfill your queries with the required data for run-time execution.
- Optimizing your DB structure – keep them small when possible, and move stale data out.
- Use mutations or query language to get nested data.
- Build parallel API aggregation methods so you are getting your answers once instead of many times.
- Minimize your TTFB per screen load.
These may sound simple, but a lot of expertise is required to execute these optimum data strategies.
I will leave you with this – it’s easy to build a new system right the first time, versus reworking existing systems down the road. So build it right, build it with the right architecture and the right data structure. This way you not only have a great design but you can also offer great performance and user experience to delight your customers.
We engineer solutions the right way for product owners. If you are a data-heavy product and want a micro-second load time – come talk to us at Smartly Built. We have literally built hundreds and thousands of APIs for some of the most complex problems and we have lots of learning behind engineering and architecting solutions.
