Code Strangelove: How I Learned to Stop Worrying and Love Development
With the acceleration of technology, being a web developer today is like being inside Stanley Kubrick’s 1964 masterpiece Dr. Strangelove. If you’re not familiar, Dr. Strangelove or: How I Learned to Stop Worrying and Love the Bomb was an absurdist look at the end of the world. More specifically, a black comedy political satire about Cold War-fears of a nuclear conflict between the Soviet Union and the United States. (Seems relevant today, no?)
Anyway, if you strip away the politics, Dr. Strangelove essentially was about how a simple decision could morph into absolute chaos. If you’re a developer like me, you immediately see parallels — how with all the advances in software development and the rise of the web, our jobs have grown increasingly complex. Simple decisions aren’t so simple now that new technology has opened a world of possibilities. And now that there are a lot more people involved in the process.
Sure, more options can mean a better end product. But often, more options mean more problems. Unlimited possibilities have sent more than one developer down a bottomless rabbit hole.
So how did we get from a time of simplicity in terms of software development to an era where anything is possible (with the right resources)?
From Y2K to Yesterday
Fifteen years ago being a developer was a solitary pursuit — an often lonely, one-person job. But these days, coders are no longer isolated. We now leave the comforting glow of our screens to begrudgingly interact with other complicated humans, often whole teams of others, all while worrying about hackers, evolving tech and the growing demand for revolutionary new products and interactions.
How did we get there? I’ll set the scene.
Close up on one guy sitting at a desk, typing on a computer. The desk has piles of paper around it. The calendar says it’s the year 2000. This is his first full-time web development position. His cubicle is decorated with a sign that reads: Code Strangelove, Webmaster/IT. He spends his days creating static web pages and fixing the fax machine.
Fast-forward to 2002. Our developer, let’s call him Code, is back at his desk, this time with a bigger monitor. Next to his computer sits a huge pile of books on PHP, ColdFusion, PERL, HTML, and Javascript. Wearing a neatly pressed suit, the office manager stops at his desk to ask him to fix the fax machine.
In the blink of an eye, it’s 2004. The office manager approaches, dressed for Casual Friday and holding a flip phone. “Hey, Code, have you heard of this new thing everyone’s signing up for? It’s called The Facebook. People post pictures of what they’ve had for lunch. It’s pretty cool.”
“Who cares about The Facebook?” Code says. “It won’t last.”
Developers Are Solo No More
Suddenly, it’s 2006. Facebook is still around, now joined by Twitter. And there’s a new person in the cubicle next to Code, hired to handle “Social Media and Design.” Code is busy reading jQuery in 5 Days when the office manager approaches and asks if he can fix the fax machine.
It’s late 2008. There are now three people in Code’s cube farm: a graphic designer wearing oversize glasses, and jeans-clad people handling web and social media. The designer approaches Code’s desk holding an iPhone 1. “I have the new Flash designs for Beyonce’s mom’s website. It’s gonna look awesome!” she says. Code is stressed because he hasn’t yet mastered the new technology and isn’t ready to build a whole site using it.
It's 2009. The new site launches after Code has toiled for months and months to implement single-page apps in Flash. Six months later, Code jumps up from his seat and announces to the room, “Flash is dead! Flash is DEAD! Steve Jobs just dropped the bomb and stopped supporting Flash.” No one responds.
Code shrieks, “Apple is going to take over the world!” The social media manager replies, “I just ordered the new Windows phone. It will have support for Flash. It’s going to kill Apple!”
Enter the Front-End Developer
Cut to 2012. Cubicles are rearranged to accommodate a whole web team that includes both frontend and backend developers. Code thinks it’s getting crowded.
The developers meet with the designer to go over a new web project.
Designer: “The designs are done for the new pages.”
Frontend: “We can’t implement those as-is.”
Designer: (shocked): “What’s the issue?”
Frontend: “The designs aren’t responsive.”
Designer: “Just copy the design!”
Frontend: “<em>You don’t understand.</em> That’s now how development works.”
Backend: “Guys, you can't fight in here! This is the Web Room.”
Just then, Code hears the office manager yell from down the hall: “Hey, can you fix the fax machine?” Code (smiling): “Nope. Not this time. Not my job anymore.”
It’s 2018 and Everything Has Changed. Again.
How we build sites has changed, continues to change. Everyone seems to be racing to get their site to feel like a mobile application. We all want fast, smooth and clean pages. Web design has evolved from a series of flexible grids to bands of content that users can read left to right.
Say goodbye jQuery and hello to React, Angular and VueJS. These Javascript platforms are intended to improve the interaction. React is the most popular. VueJS is growing faster than React and has more of the market than Angular.
Working in these javascript platforms is a profound change for developers. Frontend developers are forced to think about “components” instead of “pages.” Imagine someone moving all the furniture in your house while you slept. Morning would bring confusion.
Frontend developers are becoming backend developers. Backend developers are fractured into an evolving ecosystem of platforms. It’s increasingly unclear who does what anymore. We didn’t even mention analytics, SEO or inbound.
What is clear: things are getting out of hand. Since web technologies evolve so fast there is a constant shifting of the field. It’s possible to do anything on or over web. With possibility comes the desire to streamline. How do we do more, faster? There’s also the desire to solve other technology challenges by creating web services to manage your data.
Where does all the confusion end? How do we ensure a good outcome for our web projects?
Turn Chaos Into Commercial Success
To succeed these days, we need to recognize that change is a good thing. It keeps us focused and sharp. But often, change also adds complexity — and complexity begets complexity. More stakeholders. More reviewers. And everyone doesn’t necessarily speak the same language or have the same goal.
To counteract that, we need to focus on the core desired project outcomes and user stories. Think about your project. What do you really need? Doing a little research before jumping in can save you money.
Now that you know what you need, make sure you can execute. Get all your stakeholders and team members pointed in the same direction. How? Create a war room. No, not literally. You don’t need to re-enact Dr. Strangelove.
But create a logical process that includes developers, designers, project managers and project owners. A process that ensures everyone is heard, at the time when their input is beneficial. (For instance, a designer showing up with beautiful pages that can’t be implemented makes little sense. Fortunately, it’s a problem that’s easily corrected with process and communication.)
Creating amazing web experiences requires lots of talented people coming together to build something special. Gone are the days of the solo developer. The well-oiled team approach is your best shot at preventing doomsday building a successful product.
Read more <awesome /> web-related content.
Illustrations by Prashant Iyer@ICS.