The world of software engineering is comprised of a variety of interesting subdisciplines relating to shipping and maintaining software. These subdisciplines, ideally while maintaining context of scientific thought and fundamental engineering principles, are generally applied throughout today’s computing industry to create new or innovative technologies.
By practicing and refining these subdisciplines over many years, software engineering has evolved a [growing] set of software development processes that enable teams to collaborate and execute on an idea into production. Though software development methodologies may differ, ultimately what matters—and what these methodologies are trying to solve—is to simply allow engineers to get shit done. However, sometimes there exists engineering mindsets that negatively impact productivity despite having software development methodologies in practice. An especially dangerous engineering mindset is something I will call speculative engineering.
Speculative engineering is when you avoid solving a problem by raising other problems, questions, or scenarios without [scientific] proof of their usefulness, relevance, or validity to the actual problem. This methodology additionally extends to the process of solving a problem through arbitrary tuning. For instance, statements such as the following are indicative of speculative engineering:
- You shouldn’t do X because it will slow Y down
- Let’s build X because users will like it
- Let’s change X variable because it will make Y faster
- Let’s make X separate from Y because it will be better
Statements like these are by themselves not sufficient and should not define the direction for how a problem should be solved. Without adequate proof or measurements, these statements are just speculation. Rather than pointing out [possibly irrelevant or not yet applicable] edge cases, anecdotal references, or other non-scientific ideas, engineers would be better off just iteratively building and measuring on the problem in a scientific manner. On the other hand, while some engineers may say these types of statements are allowed because of a multitude of experience, this still may be troublesome. Relying on experience alone may not be enough as you must have confidence that a problem exhibits characteristics that makes your experience applicable.
So why do some people practice speculative engineering? It could be fascination over seeking out edge cases, fear of failure, fear of progress, or complacency among several other possible reasons. In any case, if speculative engineering emerges and is left unattended, the likelihood of a project being delayed or not being shipped could quickly become reality. Everything considered, speculative engineering is dangerous to productivity and teams should proceed with caution when faced with such an engineering mentality.