Software development is huge, it’s everywhere, into everything. It’s easy to get lost. Am I a kernel developer, an enterprise developer, or a game developer? And it’s easy to feel disillusioned when we find our skills and knowledge lacking on certain tasks as we resort more and more to Google and Stack Overflow. On top of technical knowledge we also need domain knowledge: 3D maths, physics, finance, hardware, accounting, etc. No matter how good our coding skills are, in the wrong domain with an incompatible skill set, we live in a quiet desperation.
This is a nice talk by David Heinemeir Hansson in which he discusses, among other things, how he got into software development and the type of developer he is. He accepts his limitations, and focuses on what he can do.
I think it’s important for us to consider our skills, temperament and preferences so we pursue a career that is both suitable and purposeful. We can’t do everything.
I also agree that developing software is like writing, or poetry. It seems to me, all these disciplines benefit from being concise and fluid.
An interesting part of the video is where David argues against the practice of Unit Testing, mentioning it offers few benefits whilst affecting software design down to the class and function level – essentially you have to inject state to test effectively. The whitepaper he references by James O Coplien Why Most Unit Testing is Waste is available here.
I find Unit Testing useful to drive the development of specific code. Without any scaffolding we can directly build classes or components as well as assert the correctness of complex code. However, I do agree with many points David makes, and I find Unit Testing to be very expensive, especially when it’s not factored into the cost of development. Even worse, some Agile projects are run with a fixed timeline, functionality, and budget – but no requirements. In this case, with TDD and constantly changing requirements, you spend half your time throwing away tests and writing new ones. Often developers are burdened with writing menial tests to hit a metric like 90% code coverage. Such a metric, more often than not, does not guarantee quality or correctness. What really matters is to test what is important.
It’s worth noting that functional programming eliminates many of the design problems with TDD since your classes are immutable, and your functions pure – there’s no state to inject. You can find an interesting back and forth between David and Martin Fowler at Is TDD Dead?
Beyond Velocity 