It has become a trend to have opinions on how software should be developed. No, let me rephrase that, software developers have always had very strong opinions on how they should develop software, but lately the number of opinions has increased exponentially, and as usual, everyone (including me) thinks their opinion is the right one. One typical discussion of this kind happened a couple of months ago, between very smart (and popular) developers out there:
TDD is dead. Long live testing: http://t.co/1hHOG2SV46
— DHH (@dhh) April 23, 2014
Which was answered by (and thousands of unknown strangers such as you and me):
tdd is not “alive” or “dead”. it is subject to tradeoffs, including risk of api changes, skill of practitioner, and existing design.
— Kent Beck (@KentBeck) April 28, 2014
Starting a long series of discussions, conference calls, articles, comments, etc. probably with no real conclusion at the end (I stopped following, sorry). Which brings me to the subject of this post, which is that we have no idea how to develop software. Well… we do know how to develop software, otherwise I would not be writing this lines in my computer but on a piece of paper. What we don’t know is how to develop software right. Or to put it differently, what software development methodology we should use so that the software we develop works, is delivered on time, and doesn’t crash before the end of the warranty.
Or maybe it’s the other way around? Maybe we do know how to develop software, and there are so many RIGHT ways to do it that saying there is ONE SINGLE WAY to develop software is just plain dogma. It is obvious that software can be developed without doing TDD. I’m fairly confident that TDD was not used by NASA when they wrote the code that got mankind to the moon (but maybe I’m wrong). And there are many mission critical systems out there that were developed in both statically typed and dynamically typed, compiled and interpreted, beautiful and ugly languages.
My humble opinion is that we should invest more time in understanding what helps us create better software. Having shorter (even continuous) delivery has shown to help, mainly because it validates customer requirements at the earliest possible point (and we do know that understanding customer requirements is one of the pitfalls in software development). But we don’t really know if/how the programming language affects the final product. Or how the tooling affects.
We are starting to see some research done here, and this is only he start of the process. I really hope this continues so we can get better in software development. But until that happens, dogmatic discussions will still rule (and we all like them, don’t we?).