Just like worrying, where you eventually find that you worry because you worry, because you worry. Never forget that adding complexity is always a vicious circle. You've got to keep things suited for the problem at hand. It seems -in Belgium at least- that one of those practical lesson learned after years of being an application architect somehow got forgotten over the years. You'll have to get it just right, iterate over your ideas and make changes accordingly. Which design patterns will you choose? Does the design need to be reusable? How long will the design be used?
Keep it simple and stupid software#
Another important dimension is deciding where the "heart" of your software design lies, and how and what you will use to test its evolution.Īnd maybe most important of all, which technologies will you incorporate.
The team of developers you have to work with is an equally important dimension (are they familiar with web technologies, do they work remotely, which software methodologies do they use, etc.). The complexity of a given problem is just one of the factors (let's call them dimensions) that you take into account when deciding on your software design.
Staying on top of things is a bit like a hypothetical dog, trying to catch its own tail. When you start learning a new technology, language or framework today it is not unlikely that that technology will become outdated, upgraded or obsolete before you get the chance to master it. With an always changing landscape it is becoming very hard -maybe even impossible- to stay on top of things. You've got to keep up, so that you can provide the best and most up-to-date solution for the problem you are trying to solve.īut that is not always easy. Challenges of an always changing Development LandscapeĪs an architect you have to evolve alongside the changes of your technical landscape. And in my opinion, here lies the biggest problem. We currently have the possibility to solve the most complex problems with the most advanced solutions. NET Core, JS Functional Programming, CLI tooling, bower (or is it Yarn now), NPM, event sourcing, docker, parallel computing, AI and even Quantum Computing. CQS, CQRS, AngularJS, AngularX (2,3,4,5,6), React, VueJS, VueX. In the last couple of years (probably even more so since the first major release of NodeJS in 2009) new technology stacks have been introduced at lightning speed in the.
These changes can include changes in the technical landscape, changes in your team, changes in requirements, etc. One of the many things I've learned in my career is that Software Design has to evolve, and that you have to be able to evaluate how changes impact the important characteristics of the architecture and prevent degradation of those characteristics over time. I've solved very big "problems" and I've solved small ones. I've been a software architect for a couple of years now. Simple, right? The art of simplicity is a puzzle of complexity. So, to put it simple: simple problem, simple solution, complex problem, complex solution.
Which basically means that the complexity of a software design should always be correlated to the complexity of the problem it tries to solve. For as long as I can remember, the KISS (Keep It Simple Stupid) principle has been around to remind developers and businesses to approach a given problem with the easiest (or most simple) solution as possible.
0 kommentar(er)
