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.