An Unusual Business Case for Adopting New Technology

Everyone looks for an edge in recruiting the best talent. In my opinion, there is a simple thing you can do to help your organization bring in top tier technical talent – update your technology stack. If a job candidate asks what version of Java you are using and you say Java 6, do you think that has helped or hurt their opinion of your company?

As of right now, if you are running Java 6 you are way behind. Java 7 would be a reasonable answer, but if you could say you have everything updated to Java 8 and have been enjoying the new features, you’re showing the candidate your commitment to technological innovation. That could definitely help sell top tier candidates, who can see how the company’s continuous improvement culture can translate to a personal development culture, making your company the right position for them.

Your technological state is especially clear on the Microsoft stack since Visual Studio versions are named with the years in the version; it’s the same for SQL Server. People asking for experience with Visual Studio 2008 quickly give the impression that they probably don’t care as much about building good software as people running Visual Studio 2013 or 2015. New versions may require a slight learning curve to pick up new functionality, but the improvements are worth it if quality is your highest priority.

There is admittedly an element of taste to which tools people prefer, in which case a design quality-oriented company should be able to clearly express the rationale behind their choices. Eclipse vs IntelliJ, MySQL vs Postgres, the classic vi vs emacs – each has pros and cons but people have strong preferences for one or another, often for good reasons. For some tools there are multiple viable modern options, particularly javascript frameworks.

Javascript tools and frameworks are multiplying at a prodigious rate, making choosing the most “advanced” tool a more complicated, project-specific decision. Off the top of my head, I can name 11: jQuery (2006), Angular 1 (2009) and 2 (2014), Backbone (2010), Ember (2011), Prototype (2007), Knockout (2010), Bootstrap (2011), Grunt (2011), Gulp (2013), and React (2013). Some of these are popular today and others were popular before. Grunt came up quickly then lost mindshare to Gulp. jQuery is distinctly the old man of the group but seems like it still has purpose. Angular 1 had an Angular 2 problem, in that for a while there was no migration path between the two which meant that starting a new project in Angular 1 was clouded by the fact that the technology was at a dead end. Prototype was in vogue then fell out of favor, due to complications in how the js dom is specified interacting with Prototype’s extension of basic javascript types, see this article for more information. At some point, each of these was considered the new hotness, which makes it critical that a company understand and be capable of articulating the strengths and weaknesses of the tool when making their choice.

Starting a new project from scratch you want to pick technologies that will have continued developer interest, mindshare, and a talent pipeline. Lots of people would look at those factors and choose something safe. However, new projects are the best opportunity to try something new. If you do what you’ve been doing just because “it’s the way we’ve done it before,” you risk eventually becoming a laggard. Top talent isn’t going to be interested in working for a company that isn’t showing an interest in new ideas – top tier talent is ideally interested in developing and presenting new ideas.

Image Courtesy Wikipedia

I’m not saying you need to become an innovator, or even an early adopter, but you have to be willing to try a new technology to see if it’s right for you. If it isn’t, then you have an articulable reason to give for why you are using a more dated, but more appropriate tool. Testing out a new tool doesn’t need to be on a big project, but the new tool should be something that is the right fit for something specific that you are doing. You shouldn’t force a tool on a project because it seems interesting, if the specifics of the situation won’t give you an honest chance to evaluate it. No need to engage in résumé-driven development.

In addition to the big tools and frameworks, most projects use lots of smaller tools and libraries. These can be a great benefit to developers, and give another opportunity for small-scale innovation and flexibility. But, each of these tools/libraries version independently and need to be kept up to date; even a small tool still creates overhead and a certain testing burden to keep up on any libraries you pull in. Examples include nuGet on the MS stack, Maven/Ivy on Java, and RVM/RubyGems for Ruby. Tools can help keep the little libraries up to date and organized, but then they themselves add yet another tool that should be kept up to date. And that’s a benefit too for a company. Think of each update to a small library or tool as a practice run at updating a larger library. You have to find appropriate ways to push out a new version of the library or tool to everyone, and have the testing infrastructure to say that there is no problem with the new version. You decide to make the change, regress the system and then push it out to everyone else. The scope of the tool or library being upgraded doesn’t really matter, other than determining the size of the impact if there is a regression.

If your organization is struggling to try new things or keeping up on updates because you’ve been “too busy” and you are considering hiring, try and see if you can use this line of argument to prioritize updating your tools and libraries to put your best foot forward for your candidates.


Project Euler F#

I had always heard that Project Euler was a good way to try and pick up a new programming language and I’ve been meaning to try some F#, so I figured no better time than now. For those of you unfamiliar with F#, it is a functional programming language on the .NET platform. It supports object-oriented programming to a certain extent, but it isn’t considered idiomatic to use much of it. It seems more functional than scala but not to the degree of haskell or erlang.

Read More

What is bad code?

Everyone would agree that code that isn’t syntactically valid is bad, if it is even considered code at all. But is code that works but is slow bad? What about code that works but can’t be easily followed? What if you can’t follow it but others can? What about if you can follow it and other can’t? What about code that fails in one corner case but works for the purpose it is used for? What about code without tests or documentation?
Read More

Social Developers

I listened to a recent episode of .NET Rocks with Jeremy Clark about developer socialization. It was all about how developers interact with each other – or more interestingly – don’t interact. There was one particular anecdote about lunch at a development conference where there was a single person sitting alone at half the tables in the room; that was quite eye opening for me.

There was a particular tip to start a conversation with other developers that is so simple, yet would be clearly effective. “What are you working on?” It is a simple modification to the standard networking question “so what do you do,” that sidesteps the fact that you are at a gathering of developers and know everyone is a developer already. It’s also nice since it lets them pick a work thing or a personal project, whatever they feel like talking about. I know that I am going to use it at the next developer gathering I attend.

I also appreciated the insight that developers love to talk shop, but don’t like starting conversation with strangers. It resonated well with me as I don’t like to start conversations, but love to talk shop. It seems like you just need one or two people to get some conversations going and let other people gravitate towards them to get your gathering going.


Putting this up as a place to put my thoughts down on programming and software engineering. It’s a place to digest what I’m reading, share some of what I’m doing, and try to be a contributing member of the community. Hopefully it’s interesting to others. If not maybe I’ll be getting something from it through Learning by Teaching.

I recently gave a talk to a local meetup. This is the first time I gave a talk like this outside work. This sort of thing is new for me; I’ve never been much of a public speaker. I felt I should do the talk, like I’m doing this blog, to try and give back to the tech community which has given me so much over the years. The talk was on C# to try and expand the attendees’ knowledge of the language and improve its perception in the open source community.

Despite using the language regularly for years, just putting together the presentation helped me learn more about it. Specifically, I had to go look up what the ?? operator was called (null coalescing operator), and I had to go look further into unsafe blocks since I had never needed them before. Then when giving the presentation I got a question about partial classes that I had never considered before and it clarified how I thought about them.

My advice – if you’ve never spoken before at a group talk to the organizers, find a topic and put together a presentation. Even if it’s something you know, you can still learn something from putting it together and doing it.