The following is an explanation on simple things that are wrong/shouldn’t be done. This is especially insightful in software development, when in crunch times we must adopt a not so pretty solution that just works and can be delivered in the planned time box.
But the question is: how do we know if one thing is simple and wrong vs if it’s just doing things wrong?
For every complex problem, there’s a solution that’s clear, simple, and wrong.
But sometimes, the pragmatic solution is the right solution.
Knowing when hacks can be tolerated is a skill in itself. Taking shortcuts with clear, simple, and wrong solutions at every corner leads to untenably shaky foundations. But even the most hardcore programs have clear, simple, and wrong solutions.
Is it wrong to use a relational database as a key-value store? Probably, but it might be worth it if your application is small enough and you don’t want to introduce extra infrastructure.
Clear and simple are sometimes worth more than correctness within an error margin. How precise does the solution need to be? In what contexts and edge cases (realistically)?
Other times, the correct answer is bound to change with new information. Given enough uncertainty, sometimes the clearest and simplest solution is the best bet — even if it’s wrong. More complex paths are more likely to lead to wrong sequences for startups.
#reads #matt rickard #engineering #software engineering