The only constant is change. Especially in the earliest days of product development. Technical implementations are nothing other than subtly more concrete representations of our thoughts and ideas.
Our thoughts and ideas are subject to a great deal of change thatās proportional to our rate of learning.
Inability to respond quickly to change can lead to obsolescence.
Put another way- if our software systems canāt support a new need, someone elseās software systems will.
Our industry has responded to this with a great number of tools, tactics, and techniques. Programming paradigms (OOP, FP), test driven development, CI/CD, devops, agile methods, and even some of the more recent SVPG ideas and ways of organizing teams have all helped us uncover ways to anticipate and react quickly to change.
As Iāve experienced all of this response, Iāve formed an opinion that the deeper solutions can be found in both systems and design thinking.
This isnāt to say they the former set of tools is irrelevant, this is just my assertion that Fred Brooksā assertion seems to still hold - there are no silver bullets and the best improvements weāll see will come from our ability to design. More importantly, the best improvements weāll see will come from our ability to design for change.