Just Make Me Think! The Best Technologies Force Hard Choices.

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

About these ads
Post a comment or leave a trackback: Trackback URL.

Comments

  • Cyrille Martraire  On March 26, 2010 at 2:00 pm

    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.

  • Aaron Erickson  On March 26, 2010 at 2:12 pm

    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!

  • Isaac Gouy  On March 26, 2010 at 9:41 pm

    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 ;-)

Trackbacks

  • By Links « Beautiful Discovery on March 26, 2010 at 11:37 pm

    […] 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 […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 29 other followers

%d bloggers like this: