My approach to software development
Recently, we had a startup founder with some programming experience for whom we were building a SaaS product from an idea. The product has zero users, hasn’t been pre-launched yet and has no ongoing marketing. Every week, we demonstrate the features we’ve developed to the client.
However, the client constantly insists on seeing the code, and he comes up with his own idea on the design. He frequently requests changes; one such request was to use microservices, and this often leads to deep discussions about why those changes are unnecessary at this stage, and some change requests are even over-engineering a feature.
The client argues that he wants it to be performant, even before confirming that it is functional.
In fact, microservices will increase the project complexity and maintenance. You don't build microservices unless it is really necessary.
We had been using a commercial web framework (battle-tested and in the industry for more than a decade) to build many of our clients' SaaS products. The web framework is built for performance, scaling and modularity. Many of our clients have scaled their product successfully once it has traction.
Having built many applications over the past ten years and witnessing many of them go offline within a year or two, I started to follow this rule in that order (by Kent Beck):
- Make It Work
- Make It Right
- Make It Fast
"Make It Work" doesn't mean "Make It Broken." It means building a solid foundation that is ready for optimisation, rather than optimising prematurely.
The purpose of Rule 1 is validation. At this stage, we are testing a hypothesis, not building a skyscraper. If the core logic doesn't solve the user's problem, it doesn't matter if the codebase is written in the latest, most performant framework or uses a complex microservices architecture or looks fancy.
Following these rules will also benefit our clients by helping them go to market faster and save on development costs.
Today, when a client asks for a change request that falls under rule 3 during the development phase, my answer isn't "No," it's "Not yet." My job is to ensure that by the time we need to "Make It Fast," we actually have a product worth accelerating.
Are you looking for a software development partner? Reach out to us at [email protected] , our website: www.nsn.technology.
Member discussion