It seems that perfection is attained not when there is nothing more to add, but when there is nothing more to remove ~ Antoine de Saint Exupéry

In my 15 years of experience the questions I ask the most often include the following

Is this the simplest solution it can be?

Working code is good, readable/maintainable/understandable/navigable code is even better. All of the system’s I’ve maintained are full to the brim with code the “works”. It does the thing!

One system implements CQRS by separating commands and queries into separate namespaces and none of the proposed benefits of CQRS. Commands and Queries share the same data model, do not abstract the underlying data, cannot be horizontally scaled.

A second Elixir system attempts to model Object-Oriented inheritance super-classes using behaviours, macros and multiple layers of dependencies. Adding a single field to a domain object often required updating 5 or more Elixir modules due to tight coupling.

In both of these cases, novel approaches were chosen to address tomorrow’s scalability problems, and not today’s business need. Today’s code should solve today’s business problem.

How are we going to test this?

I firmly believe that code that is hard to test is hard to maintain. Modules that hide easily tested code behind private functions can easily require DataCase type tests where unit tests are desired.

I don’t hear much about the testing pyramid anymore, but my DevOps / ContinuousDelivery experience has taught me to beware the “Testing Ice Cream Code”

Will this make us more money?

Features are great, it’s what brings in the revenue. However, feature development is also a source of complexity, be it testing complexity, production bugs, complexity in the domain model. That complexity comes with a cost, and that cost can result in negative ROI. Perhaps saving costs from yesterday’s features may provide a better return on investment.