Hello! I’d like to thank Adam and his team at Steadlane, as well as all the others involved for putting on this event. Thank you to our great sponsors, Internetrix, SilverStripe and Innoweb.

Thank you Adam for approaching me and asking me to present here. I’d like to thank him for the pressure placed on me with coming up first, but I wont.

I’m Stevie Mayhew.

I am a partner, and Chief Technology Officer at Little Giant, a Digital Agency located in Auckland, New Zealand. We’re now a 35 strong team, and still growing. I arrived from a larger agency in Wellington almost 4 years ago, as team member number 8.

As our company has grown up, I’ve learnt a lot about the risk of implementing new tech into our business.

Little Giant is a SilverStripe Partner Agency, and we try to use SilverStripe for most of what we build, if we can. I’ve personally used SilverStripe since version 2.2, which makes it almost a decade of my life. Its a long time to have been using any one technology!

But its not one technology. Its ever changing, evolving and growing. Some of my favourite people will be telling you about the latest changes and the exciting new technology that SilverStripe is embracing in upcoming talks today.

How much does it change? I’ve crunched some numbers for you.

There have been approximately 88 different versions of SilverStripe (not including alphas, betas or release candidates) since I began working with it. Thats about 10 release a year. A new version every 6000 minutes. 1/200th of a new version of SilverStripe will be built during this talk.

Thats an incredible pace, and its only one piece (albeit a key piece) of the puzzle for developing a great application for my team.

In the world of development things do change at a rapid pace. How do you keep up with the every changing technology landscape? Should you keep up with keeping up?

I’m going to talk to you about how to identify new technology. I’ll give some insight into processes I follow when finding useful new technology. We’ll discuss some of the implications of using new technology within a team and look at how the use of new technology changes over time. Finally we’ll talk about managing developers within your team and tempering the shiny things with the battle tested ones, and how to make the decisions about using each.

First, its useful if we look at the words “new technology”. We all know what technology is, but what is new?

If we can define the word new in a meaningful way, we can put processes in place to deal with it. So, in terms of technology, how can we define “new”?

One thing which I see a lot is people calling new technology “the latest and the greatest”. Not only do we, the users, say that - the marketing teams, or developers, who created it shout from the rooftops about how great it is. They tells us its the best. If its not the best, why would you use it anyway?

I like to ask my team the question “what is the latest and greatest technology” periodically and it has been interesting to see how their responses have changed over time. I’ve noticed that as a developer grows, their thinking about this question changes and they tend to respond in a more guarded fashion, with a greater emphasis placed on the justification of their response, rather than the technology that they choose to respond with. Eventually they start telling me there isn’t a latest and greatest, there is just another new technology and we should probably look into it if we have time.

Instead, lets change that definition of new to something useful. I define new technology as something you don’t have in production. Not new in your build process, or your UAT service, but until its live and running in real life, with real customers.

Its got to go out and do before its not new.

If you define new technology this way, that its new until its in production, you will have to face the fact that you are working with something new for a longer period of time than you might be comfortable. Treating it as a new technology for a longer time can allow your teams to have greater comfort when things are going wrong. It can also mean that when you finally get your application into production it can be treated as the enormous accomplishment which it is. Its important to celebrate when somebody does something new, as they will have put in a large amount of effort, and taken on a risk trying something new which they have now overcome - ultimately adding to your teams knowledge, skills and expertise. These are good things to have in your mind, because new things are scary.

Actually, new things are terrifying. If you aren’t scared of what you’ve got yourself into when you grab a new piece of technology and start a development project, you might wish to reconsider. Heres a simple exercise - take a long deep breath and list everything which can go wrong with your current technology and systems when placed in a junior team members hands.

Got a big list? Hopefully its huge. You know all these things, because you’ve been working with them for so long. Your past experience has tempered your insight into potential issues and allows you to mitigate some of the risk in development.

Pick a piece of technology you’ve never used before. Make one up if you want, people do it every day.

But don’t let me dissuade you in only 9 slides! There are some special reasons why using new technology is awesome.

When you start with something new, its a brand new world for you to explore. You get to learn the way which the system works, you get to work out who's doing what with it. Delving into something new is the highlight of my work, and something which I treasure. I am extremely protective of my time in research and development because it helps me to better understand why we’re working the way we are at the moment, as well as pick up exciting new things to try, smash and break - and hopefully eventually push to a production server.

The excitement of a new project, new technology or new beginning is, in my opinion, a massive part of why we are all still developers.

New technology is also challenging. Its challenging to not be an expert in something when you previously were. It challenges your assumptions about why what you’re currently using is the best (hopefully you use the best technology available to you). Its challenging to ensure you are doing the right thing, in the right way, at the right time. When you start out with something new, its green fields and you get to plant the flowers. Unless you have someone who can help you learn, and if you’re anything like me, you’ll likely muddle through some basic exercises and then jump right in. Thats a great challenge.

Its also challenging to make your boss let you use it! I’ll talk more about that later.

One of the worlds great truths is that as time moves on, we learn things. We can put those learnings into practice with newer technology, replacing the bad bits with the good new bits. This can mean that new tech can be the best way to do things, and makes the most sense. This naturally depends on your needs, and what you are trying to produce, but can generally hold true. We are constantly moving forward, and keeping up with that movement allows us to do better and better things.

What about the other side of the coin? If there are reasons why new technology can be great, then there should be reasons why it can not be as well.

Is the new tech relevant? Is it something which you are going to be able to use for a well thought out purpose? When you’re looking at the plethora of new things that come out, you should think about whether or not its something you can actually use for a good purpose. If its not relevant, but its something fun, you might spend the time learning it anyway. We’re inquisitive by nature after all. Working out whether or not something is relevant is really, really hard, as you never know what you might need in the future.

I am a huge fan of virtual reality, and have even given presentations on some of the web technology which is now available, specifically a system called A-Frame from Mozilla. I didn’t think that I’d ever get the chance to actually use it for work, in a production environment, but last month after almost 6 months of playing with it in my spare time, building games and taking 3D photos and videos, we started to scope a project which needed to use 3D photos to display physical locations on the web. Because of the time which I’d spent on something non-relevant to my work, I was able to easily put a prototype solution together for this in a couple of hours, and train one of my team members on how it worked and give them a head start on the project. They are now building a small competition which is based on these photos, inserting the companies logo in a game of virtual hide and seek. Just because it isn’t relevant now, doesn’t mean it won’t be in the future.

Do you have the base skill set necessary to use it? If you are looking at something new, a good place to always start is your previous experience. Is it based on a paradigm that you have used before? Is it written in a language that you understand? Does it run on a server I have access to, or could build easily? Does it change the way which my day to day work gets done?

Is it something which is going to take you hours, weeks, months or years to master? I personally don’t think its ever going to be hours, or weeks. Ensuring that you have the time required to learn when you’re starting with something new is incredibly important. Will your business give you the leeway to be slightly less productive to get up to speed? Are you scratching an itch, or do you really need to use it to end up more productive and make better quality applications?

Is the technology supported?

Its important to know how to get help when your application is broken. Are there experts nearby, or far away? Is there a paid support service? How many contributors are there to the project, and how often is it updated?

This is crucial, because you do not want to end up using something which nobody else does. If you’re like me, you’ve built your own CMS solution in the past, before turning to SilverStripe. Its definitely better with friends.

Does it make sense for you to invest your time, and your businesses time, in pursuing this?

How much time is it going to to take to train the entire team? How much time is it going to take to train yourself? How much time is it going to take to build the systems and processes around the new tech?

You’ve all heard that time is money, but I also like to think that time is also happiness. The more time that I have to do things, the happier I am. Sinking time into training, or learning, is great - but the less time that I am unproductive the more time I have to be happy.

There is a lot of technology out there. A lot. There are over 125,000 packages on Packagist for PHP. There are over 400,000 packages on NPM.

Some of its good, some of its bad.

Personally, I use both types (knowing and unknowingly) all the time. I’ve written both. Its not something to be ashamed of, but knowing when you need something quick and dirty vs when to architect the total solution and implement an entire system using old or new tech is all part of being a great developer.

Then there is the monumentally stupid. I once wrote a mail server. Well, not quite a mail server. Something much worse. I was young, inexperienced and a bit foolhardy. There was an issue where my clients mail wasn’t being delivered correctly from our current server, and I didn’t have a clue about what was going wrong. I didn’t have the knowledge to fix the issue, and didn’t have the support to understand how a mail system works and why it was being blocked. So, as you do, I figured I would start sending it from a different server which didn’t have the problem. That was simple enough - I wrote a simple PHP class which you could fire details at with a POST request and it would send the mail fine. Obviously that worked fine, until it didn’t. I think you can all see where this is going, and yes I ended up spamming a lot of people as a mail relay. Lesson learned. Using something new here would have been a much better.

So how do you make the right choice? You have to look at the reasons you are wanting to try it out.

Is it because its shiny and new? Do you actually need the tooling? Whats the driving motivation behind using it?

Could you build it yourself? More importantly, could you build it better? Obviously, not invented here syndrome is bad, but there are occasions when looking at using something else is equality detrimental to your workflow. Don’t build a mail relay, but do build the small piece of functionality that you require if there isn’t something that suits your needs exactly. Often it can be a bigger debt to try and wrangle something ill suited into your applications than spending the time crafting the exact thing you require.

So, does the technology you’re looking at suit your current needs? Does it meet every need you might have in the future? Does it go too far? Is every piece of the puzzle solved by this, or does it require multiple other moving pieces to be added? How many pieces do you have to add to make it work?

Is it the latest and greatest fad? Did you see it on Hacker News? Is it all the rage on reddit? Is it the apple of twitters eye?

People on these mediums are usually passionate about the thing they are discussing. You are going to get a skewed view of the realities of the new tech from these sources. I think of them as a great place to see new things, but wouldn’t think of using something purely because of their advocation on one of these mediums.

Does someone you really admire use it? Does someone you know use it? Do they advocate your use of it as well?

There are implications to using new technology that you have to consider wisely.

There is a huge opportunity cost of dropping your current procedures, systems or technology. The amount of time that it takes a team of developers to adopt a new technology, and become competent, can be massive. Its never good enough to have one expert in your team, you always need at least one more. Your business cant rely entirely on someone who might get sick at an inopportune moment. How willing are you to put time into training sessions, research and development and the general time it takes to upskill a developer?

Your team members should be able to edit and fix bugs and issues, and eventually build entire new systems with the new technology. Every team member should have some understanding of it, not just your specialists.

How can you drive adoption within the team? You need to ensure that there are others who are interested in, or willing to learn the technology which you are trying to use. If nobody else is interested, it becomes extremely difficult to propagate through the team. If there isn’t anyone else willing to learn, it becomes difficult to adopt the technology.

Is it a decision thats best for your company, or that is best for you? Will there be a benefit for the company when you pick up this tech, will it allow for things to be built faster, with better tests and be easier to upgrade? Or is it something that might just be for your benefit and have no lasting impact on the way which your team works?

So how can you mitigate these concerns? Its easy! Just don’t use new technology!

If you don’t want to have the hassle of new technology, seriously, don't use it. I have had hundreds of successful application builds using nothing but tried, trusted, old technology.

But if you do want to use new technology there are things which you can do to prepare.

View and try test applications. Todo or toy applications usually aren't enough, you should try and find something real world using it. Judge it by how many reviews or stars it has. SEMVER is now prolific enough that you should be able to check if there is a stable release.

At Little Giant we ask developers to present technology they want to use at our weekly developer catchups. This involves presenting the technology, the use case and a few examples of why it suits their needs. This is then be reviewed by the team as a whole, and a decision made whether or not to allow it into their stack. The developer who raised the technology as viable then becomes the champion of it internally, and the resource for everybody else when they want to use it. This means that the developer who proposed it has to become an expert and provide guidance within the team for others. You have to really want to use something to take on this responsibility, and this helps to force some good decisions for proposing to bring it into the business.

Of course this doesn’t mean that any technology that is brought up and accepted by the team will be put into use. The business may not want to use it, it might be too specialised, it might not have the support we require.

Some of your clients may not want to use new technology. Thats fine, as its ultimately their decision. You should be able to articulate the benefits which you are gaining by taking this path and let them understand how it is going to make their application better. Sometimes, it can be a bit of chicken and egg, as people don’t want to try out new things unless there are solid working examples which you have produced before.

I’ve changed the way which I use technology in my development roles over the years. I started by using whatever someone told me to. Then I started using whatever I wanted. Now I make sure others aren’t just using what they want! Learning how to approach new technology has changed the way which I approach development as a whole.

When I began my career as a professional developer I was lucky enough to have a good mentor, a man named Michael Mitchell. I would urge you all to find a mentor and use them to help you grow.

Michael showed me the ropes of doing work for which you get paid, got me using SilverStripe and gave me work which suited its use. I worked on projects with him helping me out for about two years before I decided to make it on my own.

Being a strong, independent man I immediately decided to start using something else, without thinking through any of the consequences. My first failed startup went through three code base changes in a year, starting with Code Ignitor, moving to Ruby on Rails as it gained prominence (literally the latest and greatest, top of reddit and all over twitter) and then finally switching back to SilverStripe.

Later in life, about 3 months into my working life at Little Giant I introduced the use of ReactJS without consulting anybody about it. I just went out and did it, because I thought it was cool.

However I had experience using it from a previous employer, two great resources in friends who now worked at Facebook, and the development of it was ongoing, backed by a giant company and looked like it would keep on an upward path. No, there wasn’t a stable release and it could have blown up in my face, but thankfully it didn’t. I used it to write a small filter section of a larger ecommerce application - something we now do consistently.

I didn’t have any processes in place back then. We were a smaller team, with a bit more of a cowboy attitude. As we’ve grown its been important to put the processes in place to deal with new technology, and to ensure that we are making the best decisions for the business going forward.

Now, we follow process for introducing any new parts of our tooling for front end work. This has lead us through 3 major storage systems (flux, reflux and redux for those interested) along with a multitude of other components that you need to use to successfully build and maintain a ReactJS based applications.

I really do try my best to encourage the use of new technology. I try to ensure that my team has the ability to build cool things, using the right tools. We try to make sure that we have the processes and systems in place to encourage them to try things out, and be bold about making decisions to try new things. But we want them to be bold in the right way, without the anxiety of making a poor decision.

Working collaboratively on introducing new tech and ensuring that somebody champions it within the business has been really, really good, and we’re continuing to use new things all the time.

But we have learnt to temper that with business smarts to make sure that we aren’t making decisions lightly.

So. When do you stop starting again? Hopefully never.

But make sure that you are making the right calls, with the right processes to handle them, and the right ideas behind them.