AllThingsOpen Keynote Report: Day 2
AllThingsOpen Keynote Report: Day 2
A review of the four keynotes from the second and last day of AllThingsOpen in Raleigh NC, focusing on technology cycles, design, and the history web development.
Join the DZone community and get the full member experience.Join For Free
Learn how to stop testing everything every sprint and only test the code you’ve changed. Brought to you by Parasoft.
This is a continuation of DZone's coverage of AllThingsOpen in Raleigh, NC. If you want to read about the first day keynotes, read our article here.
The second day of AllThingsOpen started similarly to the first, with Jono Bacon again introducing the four speakers of the morning sessions. This time, while community was a theme across a few of the talks, the focus of today was more on how technology has evolved thanks to the contributions of that community. The talks on the second day were much more visual-driven than the first, and you could tell that the entire ballroom was very engaged by what the speakers had to say.
I've summarized the talks below, but you will eventually be able to watch the videos at the AllThingsOpen YouTube channel.
Mitchell Hashimoto — CEO, Hashicorp
Mitchell Hashimoto is probably best known as the creator of the Vagrant build tool, and is currently supporting that tool along with many others at Hashicorp. The main focus of Mitchell's talk was on technology paradigms and how they evolve in relation to the tools that are available. Paradigm shifts happen all the time in this industry. For example, datacenters evolved relatively quickly from needing one datacenter, to several, then were configured to support VMs, followed by containers. Everything becomes more complex, while also remaining financially accessible. However, as you might expect, with complexity come challenges.
The best way to think about this is to imagine two graphs of y=sin(0) for technology and y=-sin(0) for tooling, where the x-axis represents time and the y-axis represents complexity. Keep in mind that the graphs do not represent just one technology and one tool:
Ignore the numbers on the axes.
Basically, as the complexity of a technology increases, the less tooling is available at that point. As complexity of technology reaches the maximum point, people become unwilling to work with that technology without help, which is when tooling begins to increase, and the technology becomes less complex. As the two graphs meet at the x-axis, the "equilibrium point," as Mitchell described it, the industry is at its most productive. The tooling is readily avaiable to users, and it's easy to start working with it to solve your technology problems.
As tools increase in complexity, while all the tools may not be useful for the technology they were originally supposed to help with, they introduce cutting-edge new features that push the next paradigm forward and help usher in a new technology paradigm shift. You can see this happen every day. For example, as Docker and containers become more ubiquitous and a challenge to manage, especially in production, tools like Kubernetes have been introduced to try and make things easier.
Rachel Nabors — webanimationweekly.com
Rachel Nabors wears a lot of hats. She is a web animations expert at the W3C, works with MDN and Mozilla on web animation tools, and curates the web animation weekly newsletter. Before becoming a web animation advocate, she was a cartoonist and front-end developer, and made the crowd laugh with her collection of hand-drawn slides. More proof that you don't have to use Powerpoint!
Her talk was focused on advocating for "design as a feature," of open source projects. Usually, project owners will want to focus on features, feel like they don't have time to focus on design, or believe the technical value of their project alone will make people take notice and adopt their tool. However, in the case of Sass, this was not the case. If you don't already know, Sass is an extension to help web developers use CSS easily and more efficiently. Sass' main competition is less, and while Rachel felt Sass is the superior tool, for a long time, Sass was struggling to adopt as many users, due to less' designer-friendly website at the time compared to Sass' site, which featured a logo that looked like it came straight out of the 80's:
A brand that is clearly "hip" and "with it."
Now if you clicked the link to Sass' page earlier, you'll know what it looks like now. They accomplished this by focusing on a two major strategies. The first was to start letting go of what they thought was important, such as keeping the project on Rails and brining in more CSS syntax rather than HAML. The second was to reach out to web designers to get their feedback. Designers responded en masse and the Sass team listened. Where before the front page immediately thrust you into complicated documentation, the new site makes it's brand message very clear: "CSS With Superpwers," and focused more on easing people into the onboarding process, showing off the basics of Sass before inviting them to install, and it explained how to install Sass as well.
This case study demonstrates the power of both effective design and how community can improve tools for the better. Design and branding is just as important as the quality of the tool in encouraging adoption, particularly in Sass' case where their main audience was web designers. Giving people a symbol they can easily recognize makes a world of difference in boosting awareness of your tool. However, Sass wouldn't have been able to make their changes if it hadn't been for the community of designers that helped get them there, and the biggest takeaways are to make it easier to engage your community, encourage people to participate, and make them care about your project.
Jackie Yeaney — EVP Marketing, Red Hat
In a similar vein of Rachel's talk, Jackie Yeaney was focused on how developers can and should work with a group that is often thought of as the furthest thing away from development: marketing. The first thing that Jackie brought up is, as many of us realistically know, marketing is not all fluff and feeling, and not all engineering is math, which she learned by starting as an engineer and Captain in the Air Force before becoming an IT consultant and then moving to Delta Airlines as the director of consumer marketing. Shen then compared traits of marketers and developers, and with some exceptions, a great deal of them overlapped: open-minded, passionate, hard-working, curious, and risk-taking.
As someone who started as an engineer and was thus very numbers-driven, Jackie admits that she's not often the person with the big, crazy, creative idea, and for a while it was difficult for her to be open-minded. One example she gave was when one of her subordinates came to her with an idea at Delta. Their data had shown that flight attendants had been less engaged with their passengers, so in order to get them more engaged, this person had the idea of hiring a famous designer to design new Delta uniforms. While dumbfounded, Jackie ran the numbers, saw that they had the budget for it, and gave the go-ahead. To her surprise, the new uniforms did have a very noticeable impact on employee engagement. Being able to listen for these big ideas, says Jackie, is key for both developers and marketers.
Applying engineering principles to transform marketing was the next focus of her talk, which she called "open marketing." Open marketing is a new way to engage internal and external audiences, and as you may have guessed, it's all about leveraging communities to drive results, and allows businesses to stand for people rather than just software, which helps invite more people to join the community and adopt your tools.
Scott Hanselman — Principal Program Manager for Azure and ASP.NET, Microsoft
Opinions expressed by DZone contributors are their own.