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?”