In thinking about what is so compelling about certain new technologies that have emerged in recent years, a common theme is starting to emerge. The best technologies don’t just do something useful, but they make the user think about the right things that lead to better designs and more robust software. Lets start by thinking about some of the most compelling technologies or techniques that have had a lot of buzz in the last couple years:
Dependency Injection
Dependency injection is a great technique for being able to manage coupling. At least it is in practice. But there is nothing that would stop you from using dependency injection to, say, create a giant class and inject thirtyteen-hundred dependencies in it and giving yourself a maintenance nightmare.
What is important about dependency injection, is that it makes you think about dependencies. When I am writing code, I want creating a dependency from one class to another to hurt. Not a lot, but enough that it makes me put an entry in a file somewhere – be it an xml config, or a module, or something. A DI tool that wires everything up for me without me having to explicitly think about it each time – well, that is to me like an HR management tool that does not have an “are you sure” prompt on the “fire employee” button.
Continuous Integration
Continuous Integration tools do some nifty things, one of the most important being providing some visibility to the state of the code. When properly implemented, the benefits are pretty staggering. However, in my experience, one of the most important benefits is that Continuous Integration forces you to think about how to automate the deployment process. You can’t continuously integrate if some person has to flip the bozo bit in order for the build to work. CI promotes a model that makes tools that require human intervention to install seem obsolete. I can’t see this as a bad thing.
Functional Programming
Most anyone who knows me in a professional context knows I am a big fan of functional programming. I have grown to like the syntax and expressibility of languages like F#, and there are a great many reasons why the language is important. But to me, the most striking is that functional languages make you think long and hard about state. You can do state in F# (through the mutable keyword) – even in pure functional programming languages like Haskell if you implement a state monad. But the important thing here is that you have to do significant work to create state in these languages. That leads to choices about state that tend to be more mindful than in languages where state is the default.
I could talk through more examples, but I think you get the picture. The opposite tends to hold true as well – my main issue with a technology like ASP.NET Webforms is that it makes certain things easy (ViewState, notably) that it should not, in order to help you avoid having to think about the fact that you are running an application over a stateless medium. When you are considering a new technology that is emerging – don’t think features, think “What choices is this technology forcing me to make?”
I’m glad to read that point of view on “technologies” and how they shape the way we think.
I would expand your list with TDD, that forces to think on how to make unit testing easy, hence also forces to care about dependencies, and with design patterns which for newcomers act as examples guiding toward deeper design principles such as the SOLID principles.
I also appreciate the idea that building software requires deliberate and conscious thinking. Making it work is not enough, and the more constraints the better.
Thanks! I would have added TDD and some other examples, but I was on a timeboxed iteration of 1 hour to write this blog post and get to my client for the day :)
Your point is well taken though!
In your next timeboxed interation maybe you could contribute one of the four programs F# has no implementation for in the benchmarks game?
http://shootout.alioth.debian.org/u32q/fsharp.php
It’s going to be really sad if I write them ;-)
[…] 26, 2010 · Leave a Comment Make me think This is an interesting way to measure the value of good design. Of course, it’s not so much […]