Evolving Software Architecture To Adapt With Product Growth Healthy Software Developer

Are you making decisions about what technologies and patterns are used in your software product?
Today I’d like to talk about some considerations you may wish to entertain when you select technology for use on a product being delivered to customers with software. Evolving software architecture to adapt to product growth can help your team deliver faster and accommodate refactoring needs easier as the project progresses.
We should determine how mature our product is in the market first. Geoffrey Moore’s famous book “Crossing the Chasm” describes how a product goes through segments of customers along the maturity of a product’s timeline in the market. In this video I talk about how to change the software architecture depending on where you are along that timeline as you chase market fit.
Are you selecting technologies that are appropriate for how mature the product is? If you have team members who’s only work experience was on more mature products, they may need help with making technology decisions that are simpler and support the speed of change necessary for a less-established, exploratory product.
If we select a comprehensive, full stack set of technologies for our minimum viable product (MVP), we can be susceptible to over-architecting. We can never make perfect decisions, but I recommend considering the maturity of your product in the market, and if choosing simpler architectural patterns and technologies might be better.
Once a product has growth needs, the business should be profitable enough, with enough additional revenue, that updating the architecture to meet the new growth needs can be afforded. This takes pressure off the team early on as they are able to product changes for early customers to validate business ideas quicker.
We should also consider the skill level of our team members, and whether they’ve mastered the foundational technologies upon which pattern and stack decisions are based. If a team is especially proficient choosing a more comprehensive stack may be appropriate.
If not, it may make more sense to select the minimum viable set of components needed to simply produce changes to get that market feedback as you’re still crossing the chasm.
It’s worth considering whether to innovate with our own frameworks or libraries when we select technologies for a project and how their patterns might benefit the software architecture. If we go this route, we should consider whether we really have the time and support from the business to train people on it, document it appropriately, and provide support for it.
We might consider spending more time fully researching all available options for existing components and frameworks that meet the needs of the product first before innovating ourselves. Whether using nodejs, C#, Java, python, ruby – or any other core language, there are a huge number of available packages on the community to implement most concerns of a modern architecture. The exceptions to this are the “secret sauce” where your product provides its core value – but this is what you should probably spend the bulk of your time building – NOT architectural building blocks.
You might consider resisting the temptation to select patterns and technologies that allow for future flexibility until you actually need them if ANY additional complexity is necessary to do so. Though this leaves you up to the chance to need to refactor at a later date, it also eliminates any waste spent supporting possible needs down the road that aren’t capitalized on. Emotionally detaching from having to think the architecture is “right” and will “never change” helps us have the mindset necessary to be more lean in how we develop software.
I’d encourage you to educate stakeholders whenever possible on the realities of the architecture’s suitability for the product at any point along it’s market adoption curve. When businesses understand the implications, they are often very supp