Evolution driven development?

2025/09/24 10:14 PM

TLDR; Teams that over-engineer/architect will be penalized even more now, while teams that learn how to constantly evolve a digital marketing solution will be rewarded.


This YouTube video really resonated with me - How to Avoid the Architecture Trap: Options, Not Overengineering.

Derek summarizes the whole thing at the end:

  • Start simple

  • Build in optionality

  • Evolve when the time comes

I think this approach makes a lot of sense because,

  • Xperience by Kentico's monthly Refreshes bring new features to adopt and native solutions for existing custom implementations

  • AI technology and shifting customer behavior forces marketing teams to adapt their strategy and digital experiences

  • Agentic software development makes it easier for dev teams to make those application adjustments and refactor when needed

I titled the discussion "Evolution driven development" to capture the idea that teams will build software, using AI agents or whatever other technology appears, with the assumption that it will always be evolving. The development techniques and design of the system need to align with this idea.

Thoughts?

Tags:
Project strategy Roadmap Software development

Answers

2025/09/25 9:38 AM

This approach actually resonates a lot with how I love to work, and I value clients who, sometimes unconsciously, prefer this style as well. It allows solutions to reach the market quickly and evolve as needed, while also fostering strong relationships with clients because it requires frequent, full-cycle collaboration and communication.

That said, I have learned that there are limits. It is important to find the right balance between under-engineered and over-engineered solutions. Eight years ago, I worked on a challenging project with a tight deadline. In the rush, I did not focus much on the architecture and under-engineered it, and over the years it became somewhat of a “monster.” The project became quite popular and is still active, and I continue to maintain it. Eventually, we had to gradually migrate it to a more robust architecture, which, in hindsight, was not convenient.

On the other hand, I have worked under a software architect who strongly favored patterns and abstractions. I learned a lot from that experience, as abstractions can be powerful when used correctly. However, when changes were needed at a lower level, it became quite a challenge. My point is that experiencing both extremes is invaluable for understanding how to achieve a balance of robust, maintainable, and long-term engineering.

Now, regarding the "Evolution Driven Development" approach in the context of Kentico projects I have been involved in, many end clients still see digital projects as short-term, one-time efforts, perhaps with occasional maintenance or small feature requests. Agencies embrace that mindset, chasing new clients and moving quickly from one intense project to another, leaving little buffer for ongoing maintenance. I think changing this mindset is essential for all stakeholders to fully adopt the "Evolution Driven Development" approach.

With Xperience by Kentico striving to deliver their vision while expanding the feature set, a continuous development approach makes a lot of sense. In the long run, monthly Refreshes will likely be a great tool for reacting to market needs and refining the product vision. Currently, though, I see a potential hurdle: the constant feeling of uncertainty about what breaking changes, deprecations, or new bugs might be introduced with each Refresh. Do not get me wrong, I love the product and how Kentico approaches the product management and development, but it does require end clients and agency teams to be ready for ongoing investment and effort in product evolution and maintenance.

To response this discussion, you have to login first.