JS.next: A Manager's Guide

Chapter 1. You Can’t Afford to Avoid ES6

ECMAScript 6 offers an extensive list of new features, so many that it may feel overwhelming. Each feature was carefully considered, discussed at length, and chosen to become a part of ECMAScript. Now it’s up to us to apply these new features, bringing ES6 to our products and our customers.

How can we take these new concepts and features and put them into the brains of our developers?

How can we take these modern concepts and inject them into our current projects?

This isn’t easy. The cost of integrating ES6 into your teams and your projects may appear too high.

You may feel that you can’t afford to implement these features in your world. I am here to tell you that you can’t afford not to. Consider yourself warned: the content that follows is highly provocative.

Note

While the main audience of the book is composed of development managers, I am sure that a handful of developers will find themselves here as well. If you are a developer, welcome! If you are in development management, I hope you enjoy the ride. This book focuses on JavaScript from the point of view of the browser. Server-side JavaScript environments, such as node.js or Rhino, are not covered. (It will likely be easier to integrate ES6 into those projects, though, as you have more control of the server environment.)

Throughout the remainder of this chapter, we will discuss some of the reasons to consider integrating ES6 into your current and future projects. You will also see that in the long run, it will cost more to avoid making the switch to ES6.

Innovation Debt

When talking about debt in software development, most people will talk about technical debt. Technical debt reflects the imperfect and sometimes dangerous state of your code and processes. As deadlines approach, optional features and maintenance time often get cut from the schedule. Without enough time to properly maintain code and processes, you will inevitably have to watch as your technical debt grows. Increased technical debt is something that all teams, except perhaps those with infinite resources, face regularly.

There is, however, another type of development debt that is constantly accruing: innovation debt. The term comes from Peter Bell, an amazing author, speaker, and innovator. Peter provides a concise definition:

Innovation debt is the cost that companies incur when they don’t invest in their developers.

Like technical debt, innovation debt can spiral out of control if left unchecked, possibly threatening the existence of the company.

Note

If you have time, please visit Peter’s blog and read his full explanation of the definition.

Imagine your CEO tells you that he needs a new and modern app (that your team doesn’t know how to build), built with very modern tools (that your team doesn’t know how to use), and deployed using very modern build tools (that your team doesn’t know how to configure). What would you say? Given the current state of your team, what are your odds of getting it right?

Consider your current technology stack and code base. Then, consider your current feature set versus the current business goals with their target feature set. Now think of all the training and practice that your team will need before you can create those target features. Consider your competitors’ feature set and how fast they are gaining on you, or how fast you are falling behind them.

Innovation debt is the cost you have to ante up before you can begin innovating again. So how do you pay back innovation debt? Better yet, how can you prevent innovation debt from increasing on your teams?

The answer is simple: teach your teams what they need to know so that they can innovate, and then let them practice it in the workplace.

Many teams keep their innovation debt manageable and may be able to train up a few of their current members to help bring the team back on track. However, some teams have accrued so much innovation debt that they have to hire new employees with a new and different skill set than your current team. They hope that these new employees can pull everyone else up to speed. In extreme cases, they may even plan for these new teams to replace their current teams. As innovation debt increases, the ability to avoid extreme decisions decreases.

While the “how to pay back” may seem most important, I think that the “when to pay back” is even more important. The “when” is now. Pay back small amounts on a regular basis. At least once per quarter we should all be taking strides towards paying back innovation debt.

Make time for your team members to learn and practice these new skills. Trying to pay off large lumps all at once can be too costly in the short term. Taking multiple iterations and cycles to train your teams is virtually impossible to sell to your customers, whereas smaller and more consistent bites can be much easier to swallow.

Let’s bring this back to ES6 now. Integrating ES6 can seem like a tough challenge, but it may prove to be your strongest ally. The ES6 release is not a minor upgrade to the language. It is a significant upgrade and improvement. And the new constructs and syntax in ES6 will enable your teams to make more progress faster than they ever have. Here are some tips on how you can help your team to catch up on ES6:

• They will need time to learn it, even those who are already skilled JavaScript developers. If you don’t dedicate enough time to learning and training on ES6, your teams will struggle.
• Create goals around learning ES5/6 and other modern JS libraries/frameworks. Projects like AngularJS, GruntJS, and Bootstrap are a few that I am partial to. A daring few may even jump into server-side JavaScript, such as node.js and Rhino.
• Make sure your teams have the resources they need to learn the latest technologies. Then ask them to implement those technologies to help reduce the technical debt.
• Lead from in front instead of from behind. Help lead the way by regularly scheduling team training. Even if they are merely informal meetups, make time for the team to sit down and talk about what the next steps are.

Do what you can to create a healthy culture on your team, one that harbors innovation. For example, at a past job, we ordered 100 AngularJS iron-on badges. We handed those out to engineers who released an AngularJS app into production. At our monthly JS Ninja meetup, we ceremoniously handed out the AngularJS badges to those who released their app since our last meetup. We were surprised by the results. Many of those badge winners were on teams that we never expected to adopt such modern and fun frameworks. It was encouraging to see the team members innovate and learn JavaScript. Nowadays, you can spot these badges all over the building, each one a reminder of our goal to continually innovate.

Direction of the Industry

With one exception, today’s popular browsers will all provide support for ES6 as early as the end of 2013 (see the ES6 compatibility chart. The one exception is obviously Internet Explorer. Apart from IE, the other popular browsers all have automatic updating turned on. This means that when a new version of the browser is ready, a version with support for ES6 perhaps, their users all receive the update automatically. Within a few weeks, most users have the new version. After a few months, over 98% of users will have the latest version. Not only do the popular browser vendors have auto-updating built in, they also adhere to very short release cycles. This means that we don’t have to wait years between releases, as the updates are only weeks apart.

So if everyone besides IE users will be ready for us to use ES6, what should we do? Chapter 4 explains a handful of options for supporting your IE users without completely abandoning them. Here, however, I want to talk about what a handful of organizations in the industry are doing to be prepared to implement the latest ES6 functionality. The following are all recent examples of what the industry is doing to prune support for stale browsers.

jQuery

Every day, hundreds of millions of Web users load pages that run jQuery. When you consider the various popular JavaScript libraries, there is one that is far beyond any other in terms of adoption. jQuery is the only one that is on over 62% of the top 10,000 websites and over 53% of the top 100,000 websites. In the beginning, jQuery set out to provide a single way to do things across different browsers. In more ways than we can count, jQuery has changed the JavaScript landscape forever. It has proven itself by breaking down barriers and getting developers to sit down and begin using JavaScript.

jQuery is making a statement about stale browsers. Starting with jQuery 2.0, jQuery no longer supports IE 6, 7, or 8, what they call collectively “oldIE”. They will only support IE9 and beyond. This change will affect millions of Internet users. Website owners will be forced to decide between sticking with this older version of jQuery (thereby stagnating and capitulating their progress in order to have backward support for older IEs) or upgrading to the latest jQuery (thereby dropping backwards-facing browser support). More information about why they decided to do this can be found on jQuery’s blog.

Google

The king of search, Google, has a similar support strategy. On their help and support page for sites such as Google Apps, Google spells out their policy for supported browsers. They support the current and previous version of all major browsers. In their documentation, they explain their reasoning:

At Google, we’re committed to developing web applications that go beyond the limits of traditional software. Our engineering teams make use of new capabilities available in modern, up-to-date browsers. That’s why we made the decision last year to support only modern browsers, which also provide improved security and performance.

Rather than spend money to help people limp along in their out-of-date browser, Google opted to spend money innovating and gaining a competitive edge by building websites that “go beyond the limits” of traditional websites.

Kogan.com

One last example of the direction of the industry demonstrates in-your-face boldness.

An Australian electronics store, Kogan, took a strong stance against stale browsers. As of June 2012, any shopper checking out in IE7 or lower will be charged a special IE tax. The IE tax rate is 6.8%, which is 0.1% for each month since Microsoft released IE7 and the date Kogan.com rolled out their IE7 tax feature. The following is Kogan’s explanation to the user about the IE7 tax:

IE10 Is the New IE8

A few years ago, Paul Irish wrote a blog post titled “IE[x] is the new IE6.” He pointed out that all new versions of IE will eventually become the same as each prior version: outdated, slow, and insecure. If you have time, please head over to his blog and read his explanation.

Just as Microsoft stopped shipping IE updates to XP users (ending with IE8), I expect they will stop shipping IE updates to Windows 7 users as well. Perhaps IE10 is the last version of IE that Windows 7 users will see. This means that while IE10 may appear up-to-date today, in just a few short years it will be as outdated as IE8 is currently. Knowing how much it costs to support IE8, and knowing that IE10 will eventually cost just as much (or more), doesn’t it make sense to avoid supporting IE altogether? Knowing the headache that it will be in a few years, it makes sense to completely avoid it upfront, side-stepping those costs before they are ever incurred.

Conclusion

The industry as a whole is largely on the fence with regards to abandoning “oldIE”. However, two of the biggest movers in the game (jQuery and Google) are herding people to modern browsers. With that, they are saying: When faced with spending your money on stagnating to support “oldIE” or innovating and building the apps of tomorrow, always bet on tomorrow. It will help you retain a competitive edge and keep your teams sharp.

Please check your pulse. If reading this section has raised your heart rate, no worries. Recommending that you drop support for IE6, 7, and 8 often has that effect. If this is you, go ahead and skip to Chapter 4 and read Graceful Degradation, Traceur-Compiler, and Chrome Frame. These offer serious solutions that will allow your team to use ES6 without completely abandoning IE users in the process.

Recruit and Retain Top Talent

Suppose that your team has an open spot. You would really love to fill that position with a rockstar developer. You know the kind I’m talking about. One of those developers who sleeps using a keyboard for a pillow. But where can you find this (He-Man or She-Rah)-gone-programmer? A better question would be: what can you do to make them come to you? And an equally pertinent question would be: how do you keep them with you once you’ve got them?

Unfortunately, limitless sodas, snacks, and an arcade machine aren’t considered perks anymore. These days, it’s common decency and is expected. Still, employers have many opportunities to draw in and keep a top-talent developer. One of those opportunities is your technology stack.

You can’t take away a ninja’s sword and ask her to keep fighting. She needs her sword. In the world of the JavaScript ninja, there are things you can do that will make her feel like you’ve taken her sword away. Things like telling them that her cutting-edge experience needs to be throttled back to match decade-old standards. If decade-old standards are your target, I would ask you: do you really need a top-talent developer?

Telling her that she can’t innovate is another way to make her feel like a sad, swordless Ninja. On page 62 of his book The Myths of Innovation (O’Reilly), author Scott Berkun asserts that when we mix innovative people with frustrating situations that prevent them from innovating, those people will leave. His examples range from Michelangelo and da Vinci, to Apple, Google, Microsoft, Yahoo!, and HP. Each of these are examples of people, or groups of people, who were frustrated by the limited thinking of their peers or management. In each case, the frustration, combined with their need to innovate, forced them to seek out another home for their ideas. In each case, their innovative thinking proved to be very successful.

This type of frustration will result in employees finding another home. Rockstar “bro-grammers” and “diva-elopers” need a place that can keep up. The best way to keep them is to feed their need to learn and trailblaze, and allow them to keep disrupting. Adopting ES6 as a standard will help satisfy your innovators’ need to learn and practice those new findings. It will fulfill their need to become current and disrupt, without incurring unwanted risks for your organization.

Truly, ours is the job of coexisting with innovators rather than forcing them out the door to find a home for their ideas.

Efficiency

The term “efficient code” can have a few different meanings. The many new features in ES6 can each be categorized as satisfying one or both of these definitions.

The first is: does it run efficiently? If I write code using the new ES6, does it run faster than code written in ES5 and earlier? Many of the features in ES6 are runtime optimizations. Many of these new features have been taken from other languages, where these optimizations were found and implemented.

The second is: can I write it more efficiently? I was unable to accurately attribute the following quote to any single author. However, consider the following:

If I had more time, I would have written a shorter letter.

— T.S. Eliot / Blaise Pascal / John Locke / Ben Franklin / someone else?

In other words, if the author of this citation had been given more time, he could have summarized his message by formulating a more precise and concise response. In programming, the same is true. Most code could be reviewed and written with fewer lines.

Does ES6 make writing code more efficient than previous versions of ES? The answer is unequivocally “Yes!” ES6 has a handful of new features that will save you dozens of lines of boilerplate inside each function. For example, writing “Classes” in pre-ES6 versions of JavaScript is much more verbose than doing the same thing in ES6. And so it goes with many other features. Not only does coding with ES6 constructs help your developers make more progress, their code will run faster than it ever has before.

The World Is Changing

In Innovation and Entrepreneurship (HarperBusiness), Peter Drucker said the following about management:

Management tends to believe that anything that has lasted for a fair amount of time must be normal and go on forever. Anything that contradicts what we have come to consider a law of nature is then rejected as unsound.

Moving away from heavy “oldIE” support may be met with resistance. Transitioning your web architecture from server-side templating to a heavy, front-end templated solution may also be met with resistance. You may even be the one resisting. Those who have seen success in the past tend to think erroneously that their one road traveled is the only road worth traveling. As Drucker suggests, proposing alternatives to tried methods is often “rejected as unsound.” This is a myth of management that we can help overcome.

I recently had a conversation about implementing a newer server architecture than had ever been used in our organization. I was told that “old technologies with six- to seven-year proven track records are what is needed in an enterprise arena.” Additionally, I was told that “these newer projects (that I was proposing) change version numbers on a daily basis.” The person saying this meant that these constant commits were a sign of instability, which scared him. To these two comments, I had two responses. The first is that IE7 is six to seven years old. Was my friend suggesting that we roll back all production to IE7 standards? He shook his head. Second, if I have to choose between an architecture that has dozens of commits per day versus two or three commits per year, I choose the more active platform. If the community around your architecture can’t manage to commit updates and fixes on a daily basis, then you are on a platform that doesn’t have any demonstrable longevity. Platforms with active communities that innovate are the platforms of tomorrow.

Technologies don’t need to have a record-setting trend before they can be safely adopted. Five years ago, jQuery was a dark horse. Now it’s so popular it can be used as a verb. Just as you can say “Google it” or “Facebook me,” you can also say “jQuery that up.”

Some of the most beautiful parts of the Web would have been rejected if we all bought into this myth. We would still use XML instead of JSON, and SOAP instead of REST. Teams need to evaluate technologies on their merits. We need to trust in our ability to innovate now and refactor later on, where needed.