Hi everyone π
I want to find out more about what strategies do other companies have when dealing with problems that have multiple, seemingly equally good solutions? Maybe when discussing the topic of integrating new technology, or when solving a difficult edge-case?
Is there a process behind it? Are you thinking more short-term or long-term? What happens if you made the wrong choice?
I'd love to hear about any and all of your experiences. Thanks!
Top comments (5)
My question about the "seemingly equally good solutions" would be: what factors have you considered apart from functionality?
There are many factors that determine the value that software delivers to people. Performance, reliability, cost, time savings and so forth.
The interesting question is: what factors are the most important ones for your product, which ones are less important? And once you know that: what are your exact goals?
In many cases, these questions can only be answered by business, users and developers together.
Working as an architect, I've seen developers often neglect these factors. In contrast to functionality, they can't be implemented directly, but result from the decisions you make. That makes them harder to grasp. But they often make a bigger difference between solutions than functionality (that often can be implemented with various frameworks that are subject to personal preferences).
I generally advice to start addressing the high priority factors early in development, because of the risk attached to them. For example by building prototypes and testing them.
And then, revisit the factors regularly if they still match the situation you're in.
To adapt to new situations, build software that can easily be refactored. The only sensible, safe way I know to do this is having enough automated tests.
Use modularization techniques - microservices, hexagonal architecture, whatever is a good fit - to further simplify changing decisions later on.
I also find it helpful to document important architectural decisions in a lightweight manner.
These are my 50c. I hope this helps a bit. Questions/comments welcome :-)
Really like your answer!
My question would be: in the prototyping phase where you're testing hypotheses, do you bother with documentation and tests, since they are likely to be changed/forgotten, and will slow you down?
Specifically for prototypes for checking factors like performance/reliability, I would implement automatic tests for a very limited slice of functionality that cuts through the layers.
For other prototypes to discuss the functionality early with users, I often found "throw away prototypes" helpful. So there, you would have no automated tests and no comprehensive documentation for these prototypes.
What is the average lifespan of your software? If >= 5 years, then youβd want to consider long term.
Some long-term questions to ask are:
Some questions to start you with. I agree with Bertil around documenting the decision and reasoning behind it - will help future developers and maintainers to understand the context.
Hope this helps. π
Awesome answer! I really like that you addressed the question of communities behind different solutions. Is it actively being maintained, how popular is it and so on... Most people start caring about those things too late.