What Does Changing Someone Else's Code Have In Common With Defusing A Bomb?

A while back, the above picture bobbled up my twitter stream...it was a morning of a weekday if I remember correctly...and as I was about to bop my head in agreement and push the retweet button: a gesture to show the picture also holds for me...It slowly struck me: that was not the case... this does not hold true for me...maybe it did before, but not anymore.

See, I understood the sentiments expressed in the picture so perfectly well. Either due to building on a codebase written by someone else (aka a former employee), or working on the same codebase with other developers. That apprehension of approaching someone else's code. That feeling of things blowing up, in unpredictable and unexpectable ways was just too familiar.

But there I was suddenly, realizing it has been quite a while since I felt that way when writing software with my peers at work...the question then was, what changed? Thinking about it, I would say there are two things responsible for this change: Switching to a statically, strongly typed language, and embracing test backed development.

Switching to a Statically, Strongly Typed Language.

Before then, I had mostly developed with languages without a decent type system. I did backend development with one of such languages and then switched entirely to client-side application development where the language of choice is a dynamic, weakly typed language. On changing back to backend development, I decided to now go with a language that is statically and strongly typed: which turned out to be an eye-opener.

I will be quick to say I was one of the folks who initially never appreciated Types and statically typed languages, as I admitted in the post: Why The Hell Do I Need Types? Because Fahrenheit can't be less than −459.67 I felt they were an unnecessary overhead and restrictive...but I later "got it" and I could see, and appreciate the benefits.

With a language that has a decent Type system, I could easily approach an existing codebase and see how things fit together (even without having to run it!). Being statically typed also ensure that I get to know when things go wrong at development time and not at production time.

Test Backed Development

I embraced writing tests as part of the software development process. I am not referring to this like Test Driven Development. Clearly, my development activities were not driven by tests, but I picked up the habit of backing, as much as possible, every feature or bug fix with a unit test (or integration test). 

Test Back-ed Development: (TBD? not even sure if that is a thing?)...made it possible to quickly know when things go wrong. If any of the tests that backs up a feature fail, that is an early and clear sign that things have gone wrong somewhere...I no longer have to wait until production (or run the application) to get this feedback.

And it just makes sense that It bothers on being axiomatic, I mean it is self-evident, right? How can you write software and not write tests around it? 

Not to say everything is now an affair in heaven with these two things: it comes with...can I call it...some costs? For example, it requires more discipline to always back development with tests (but we all know discipline makes strong developers, right?). Also, even with these two things in place, when working on a badly architectured software, it might be difficult to wrangle in a new feature without feeling like a wrestling bout with the codebase...

But now I am rest assured, once I manage to wrangle in that piece of functionality or get that piece of existing code to behave slightly differently, It stays that way...and won't blow up in my face unexpectedly and if perchance something goes wrong, most of the time, I get to know before the code hits production. This way, I can rest easy.

So to the initial question: "what does changing someone else's code have in common with defusing a bomb?" The answer is...nothing!

If perchance the picture above captures your situation, the chances are that you are not using the appropriate tool for the job, or you indeed have the right tool but using it wrong: Refactoring someone else's code (or even your code) should never feel like an exercise at bomb defusing.