Boring, the new cool tech choice

 

With almost 20 years’ experience working in real estate and technology, Jai Ivarsson is realestate.co.nz’s Head of Product and Development. Here, Jai explores why tried and true technology is often a smarter choice than the latest “cool” tech.

 

The question other developers ask me most often is: “What technology are you using?”. Before joining realestate.co.nz, my background was working with start-ups, so people often expect my answer to be full of new and interesting bleeding-edge tech. Instead, my answer seems to surprise those who ask – and sometimes bore them. 

This speaks to a fundamental question that a lot of new projects start with: "What's the latest cool technology I can use in this project?".

This desire can harm the success of a project not only in the early stages but often long after the project has been delivered.

I'm definitely guilty of this myself. New technology is exciting and getting to try it out on a real project means spending time learning new techniques and solving old problems in new ways.

However, for most projects this isn’t the right approach and I would actually warn against it.

At realestate.co.nz, we look at the old ’boring’ technology option first. Most of the problems web developers are trying to solve have been solved somewhere before, so we more often than not find an answer very quickly. Even better, my team usually have had prior experience using the technology, which means the project can be delivered sooner.

 

Boring == Productive

One of the biggest wins from utilising mature technology is around the developer community. Mature projects typically have great documentation, lots of chatter from blog posts, loads of Stackoverflow answers and there’s generally an accepted ‘best practice’ way of using them.

Contrast this with most new frameworks and libraries where one of the biggest complaints is that there is little to no documentation and nowhere to get answers on how best to do something.

For frameworks that allow for it, mature technologies typically come equipped with a large array of modules that you can use to extend your project quickly, without having to reinvent the wheel every time you implement a new feature.

 

One man’s boring is another man’s risk

A key to all of this is understanding your definition of ‘boring’.

Different development teams will vary when it comes to experience and knowledge. For example, as good as Ruby on Rails might be, introducing it to a PHP team well versed in Symfony would negatively impact a project’s success.

This kind of mistake will most likely affect stability and user experience due to the lack of domain knowledge when the first lines of code are written in.

All technology teams should have what I call The Boring List. This is a list of technologies the team are comfortable with, have a proven track record with (both internally and externally) and ideally have strong documentation and supporting content around.

Adding something to this list should be done with great care and thoughtfulness.

 

All rules are made to be broken

There are of course times when circumstances dictate using something that doesn't fit all of the criteria above. There may not be a way to do it with you current Boring List and in these situations it’s important to get your priorities clear. Adopting a new technology choice is an investment and just like any other investment, doing your due diligence is very important.

 

Here are five questions to ask yourself:

1. How mature is the framework I’m thinking about?

I have used pre 1.0 technology releases in the early phases of a new project in the past, but only when it was clear that the tech would solve a problem set in a way that nothing else could.

This early adoption is both a blessing and a curse. Having a jump start on the technology made us more efficient, however last-minute changes made to the tech as it neared official release made using the latest version challenging.

2. How good is the documentation?

It’s important to establish how easy the tech will be to implement. If you are having to look at the source code for every answer, productivity will suffer.

3. Who else is using it?

Marco Arment warns against being the biggest user of any given piece of your technology stack. In these cases you are often signing yourself up to be de facto caregiver of the project.

If this tech becomes a significant part of your infrastructure, then removing it could be painful.

4. How big is the role of this choice in your infrastructure?

If this tech is going to play only a small part in your overall infrastructure, the risk is greatly reduced.

Consider how big this piece of the puzzle is and how it will affect other aspects of your work.

5. How much potential does it have?

Establish whether this piece of tech has the potential to be a valuable asset long-term.

When I take a chance on a new piece of tech, I find that there’s one important way to measure its success: Whether it gets promoted to The Boring List.

 

Leading edge shouldn't mean bleeding edge

I've had a saying for a long time: "If you aren't living on the edge, you’re taking up too much space". We all want to build projects and features that lead the way in some way shape or form. Pushing boundaries is how we progress.

But building a leading product or service doesn't mean you need to bet the house on bleeding edge tech. So, next time you are about to start something new, think about how much time and effort you could save by reaching for a boring technology choice.

 

Jai Ivarsson is realestate.co.nz’s Head of Product and Development. With experience working with successful start ups, Jai specialises in finding pragmatic solutions that allow for fast growth. Connect with Jai on LinkedIn here.