This post is a classic example of the false dichotomy between testing and types.
Daniel C Wang

In 10 years across 5 enterprise roles I’ve seen the vast majority of bugs are coming from:

  • Integration with legacy systems
  • Poor (or completely absent) TDD
  • Overall poor quality code

While on social media we have pie in the sky notions of working with the latest technologies, the sad reality is that in your average software role (or even some start ups) you’re going to be integrating with systems that are an upwards of 25 years old or software written by cowboys. Anything else is a pipe dream for the NUGS.

I have never seen or recall any significantly painful bugs introduced by a good SOLID application of types. I mean if your code doesn’t compile, it doesn’t have the opportunity to produce bugs. I have seen, however:

  • Inadequate application or abuses of static typing
  • Devastating runtime problems that cost innumerable man hours over several teams that were caused by one-liners that could have been avoided with static typing.
  • TDD taking on the role static typing (e.g. x must be a string)

I’ve heard people tell me that static typing is too much work. That’s the same excuse used for not writing exhaustive tests. There’s also a craving for immediate feedback, which good use of a static type system impedes because the role of a type system is to humble you before you hit the runtime.

Engineering sufficiently complex software is very hard, and the application of static typing simply determines whether you fail fast or not, unless you treat static typing like a cutesy plaything and forego the best it has to offer. But static typing cannot save you from bugs arising from integrations with systems that do not themselves apply static typing or TDD very well.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.