Adapting our approach for the context
Amongst the many posts written recently about unit testing one which I quite liked was written by fallenrogue where he describes how in different contexts/cultures a different approach is favoured which means a technique like TDD might not work so well.
cashto, the guy who wrote the original post, agrees with this in the comments on that post:
Absolutely right. I write apps on mobile devices in C++. What works for me may not work well for someone who designs websites with RoR, and vice versa. Context definitely matters — it was one of the points I was trying to get across.
Recently I’ve started noticing that it’s quite beneficial to consider the context that we’re working in for all sorts of approaches we might want to take.
Immutability
When I was first playing around with F# I liked the idea of having everything in the code being immutable and I decided that it would be interesting to try and apply that idea to the code I wrote in C# on the project I was working on.
Unfortunately it didn’t work out as well as I’d hoped because it requires more code to do that, it’s not really idiomatic C# so it was confusing to my colleagues and we ended up having objects hanging around which weren’t updated with the latest state changes because I’d forgotten to re-assign the variable to the new instance.
I still think that we could probably make more use of value objects in our code but I’m not convinced that aiming for immutability everywhere when using C# is the way to go.
If it was a different context such as a problem we were trying to solve in Haskell or to a lesser extent F# then it would make perfect sense.
Confidence changing code
Another example of this is the confidence that we can have in making changes to the code base.
I’ve worked on projects where there’s been a lot of test coverage across the board and also ones where there wasn’t.
With the latter we’d have to put some time in to get tests around that code before thinking about making big changes.
If we don’t have the time to do that then we need to be quite careful when changing code since we don’t have a quick feedback mechanism to let us know whether we’ve broken anything or not.
Final thoughts
Corey Haines wrote a post on pragmatism about a month ago where he suggested the following:
Often times, people use the term 'pragmatic' as a way to hide a lack of skill and experience. Or, sometimes, it is used in ignorance: someone doesn’t realize that they don’t understand something well enough. Usually, though, it is brought to play when someone is justifying cutting corners on something.
I think this applies when deciding that an approach isn’t useful in our context. We need to be careful that we’re not just making excuses for our lack of skill in that area.
When I first started working professionally in software development I was fairly convinced that there would be an optimal approach to take in every situation that I just didn’t know about yet.
A few years later I’ve come across a lot of really good approaches to solving problems but no approach that is applicable across the board.
About the author
I'm currently working on short form content at ClickHouse. I publish short 5 minute videos showing how to solve data problems on YouTube @LearnDataWithMark. I previously worked on graph analytics at Neo4j, where I also co-authored the O'Reilly Graph Algorithms Book with Amy Hodler.