DEV Community

Discussion on: How does your company choose between two possible solutions?

Collapse
 
bertilmuth profile image
Bertil Muth • Edited

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 :-)

Collapse
 
jurajmalenica profile image
Juraj Malenica

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?

Collapse
 
bertilmuth profile image
Bertil Muth

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.