New Technologies, Old Practices

I was chatting with an ex-colleague a few weeks ago and we were discussing new technologies, and how in today’s world of software development we’re redefining fundamental questions like “how we store data” or “where we execute code” that we haven’t done for a while. Javascript is becoming more and more powerful, with quicker browser runtimes, and server technologies like SignalR, OData stacks and WebAPI and are making it easier to talk directly to the browser client from distant servers. Meanwhile we’re also reevaluating fundamental questions in the data world. Should we continue to try to solve all our data questions in a relational database? Do we look at OLAP sources? What about NoSQL options etc. etc. In the background of all this is the emergence of viable, easy-to-use cloud solutions. It’s an exciting time for us developers from this perspective.

The Risks of Adopting New Technology

At the same time, we must not assume that simply using the latest technologies means that our solution will be default be a good one. Vendor technologies are there ultimately, as a means to an ends to more quickly write solutions that have exhibit the right qualities from a development perspective, which include (at a high level) things such as maintainability, readability, performance etc. etc.. whilst at a lower level might mean adherence to SOLID principles, quality unit tests suites etc..

Many demos you see of technologies will not discuss their applicability to these qualities, and how easy (or not) they are to fit into that. For example, when Entity Framework first came out it wasn’t really testable to the extent that it is these days. You ended up having to put all your queries behind a repository when you already had a repository pattern built in called ObjectSet<T>, along with all the LINQ extension methods. There was no way to test ObjectSet, so you had to treat it the same as you would e.g. accessing the file system.


I guess the point I’m making is that “technologies maketh not a quality system”. Don’t forget best practices and adages like KISS and DRY.

If I was to work on a new system tomorrow, of course I would ask what technologies it would be written using. But I’d also ask what the team’s approach to unit testing was. Do they understand concepts like SRP and DI etc. etc.? In fact, I would probably prefer to work on a system that used older technologies but was written to a high standard rather than one that was written in the latest technologies but did not have any unit tests.

When it comes to new technologies, anything that you can do today, you could probably have done five or ten years ago – it just would have meant writing more code yourself. So treat technology for what it is – a tool to get things done quicker, possibly to a standardised pattern – it’s not an excuse to forget the fundamentals of quality software.

Leave a Reply

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

You are commenting using your 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