Is Web Development Dead?

Personally, I’d give it about 5 to 7 more years, maximum 10. I’d even kill off web design alongside it. I am talking about website development, specifically where the developer is concentrating on writing code that manifests directly on a website, rendering HTML and Javascript.

Web development is a broad term though because API development that manifests as JSON data across HTTP requests could also be considered web development.

When web design was a top role for designers, about 12-15 years ago, it was because design demands were rooted in print design. This was before mobile phones were a viable browsing tool, so you could bank on having consistent screen sizes. This was also at the time when broadband for the home was common enough that the average person could view a complex website that was so abundant with a skeuomorphic design that the bandwidth requirements were high, but the quality was high as well. As a result of complex design, web development was also a dominant role, because it was a lot of work to develop alongside that complexity of the design.

But as mobile device usage has grown, and the separation of concerns from websites being king, to instead a combination of websites, apps, and other services, the website’s need for being gloriously designed decreased. Given that we continue to have an increase in device variety, this trend is not going to reverse itself. A simple, clean design is best suited to auto-adapt to the variety of screen sizes and types that will be available for decades: visually, this is all the way from a wristwatch to a billboard.

Based on that, the majority of website development has already shifted to more data-centric work, above design-centric. If I’m viewing website content on my computer, the design might matter to me. But when I switch to my phone, design (at least, heavy graphical design) is only going to get in my way. The design components that will matter on my phone are color, typography, readability, etc. There will still be a need for designers, but far less than what we needed a decade ago, and certainly less than we need now. Designers will need to branch into more cross-device creative direction than simply “website design.”

And developers are already heading that way, by avoiding design and focusing on API development, which is critical for driving website content while also driving the two other most important technologies needed right now:

  • Apps, which are currently manifesting primarily as mobile apps, but which also include voice-activated apps, and VR apps (through independent devices like what Google tried with Glass), and
  • Integration, which is the data-sharing aspect of API development that allows the data from one app to be integrated with the service of another app to provide suite-like features across disparate systems.

When a design is needed, most of the existing frameworks can already handle 95% of the design needs a company has. What we’ll be lacking though, unless the trend changes, is qualified business experts who can properly capture web application needs from business owners to develop solutions that fit company requirements. The demand will be on making custom applications at a fraction of the cost of what it used to be. The more APIs there are out there to perform the functions we need, with integration at their core, the more a website is just going to be a clean merger of technologies from a variety of sources, and design is going to remain minimal, because that same content needs to adapt to varying phone sizes, a watch, a lens over my face, an audio interface reading back to me, VR projections from a headset, and so forth.

So web design and development as we know it today, is going to be mostly gone within a decade. API development, app development (in many forms) and systems integration will be the primary focus.

If PHP “does’t scale” why use it?

I would summarize:

The main issue is that server time is cheaper than developer time.

A scripted language like PHP (or Ruby, etc.) takes about half as much time to program as bytecode or compiled language like Java (or C, C++, etc.).

So if you have a team of 10 developers each paid $100K, then you are paying out $1M in salaries. If you replace Python with Java, now you need to hire 10 more developers and pay out another $1M. In exchange for what, saving $50K of server time? Obviously, that’s not worth it!

If you already know PHP then go with it. Especially if you want to get to market as soon as possible to have an early mover advantage. Experienced PHP developers know that they could find out where to optimize once their site is in production and its features had been decided on.

This is a good example for other startups. The combination of rapid development time and flexibility on the front end and speedy service time on the backend is a good example to imitate.

As a professional PHP engineer:

The stigma that PHP applications don’t scale well comes from the fact that many inexperienced programmers choose PHP for their web applications. This is because PHP is an easy language to learn, integrates extremely well with Apache, and is supported on nearly every host in the world.

Inexperienced programmers will often use bad practices when writing code. Given enough of these bad practices littered throughout the web, written in the inexperienced programmer’s favorite language, it’s easy to see why some people are averse to PHP.

There’s also, probably, a “holier-than-thou” attitude that some programmers have toward PHP (again, because of its simplicity).

PHP scales just as well as any other language when page caching and best practices are taken into account. There are plenty of well-used PHP projects to prove it.

Return of the Senior Engineer

To paraphrase Mark Zuckerberg, there is a widespread feeling that young people are smarter and senior developers are not needed. But, when you look inside most businesses, you see businesses that are being held back by a lack of senior developers.

What did the founder of one of the largest tech companies mean by this?

Many new startups typically take a year to produce something that is ugly, full of bugs, inflexible, poorly written and practically (but not absolutely) unusable. Then, in year 2, they re-write the entire product which is 10x better yet is plain, still full of bugs, still inflexible, poorly written in a different way and somewhat usable. Finally, in year 3, they re-write the entire product for the third time and, before it is delivered, the investors give up, the startup runs out of money and the startup folds.

This is one reason (but not the only reason!) that startup failure is so high. The startup built the wrong thing in the wrong way and paid the price in years of development time and millions of dollars of venture capital.

Differently, in the biggest tech corporations, the product just slows down and creeps along. After years, the product is reasonably attractive, has a “big” codebase and is not very flexible. New features are small and mundane, and, in the worst cases, simply visual (“a new coat of paint on an old car”). Developers add to the mass of code but simply don’t have the technical ability to see into the codebase and make the changes necessary to make big, new features possible.

First, is it reasonable to expect one senior developer unwind 2 years of design and code chaos, bring to heel a 10-person team of non-senior developers who continue to produce code and whip the product into shape in 6 months? Is it reasonable to hire Michael Jordan to lead your team of rookies in the mid-season and expect him, by himself, to win the NBA championship for you? Yet that’s what a lot of companies expect: that they can hire ONE person to supercharge an entire team or even turn nothing into something amazing.

At a startup, it’s possible that the right senior developer(s) could get the startup to year 2.5 in 1 year. Instead of having your developers finally producing a sell-able product just when it’s too late to matter, you can save a lot of time and some money.

At a big company, the right senior developer(s) can clean up your code base, make it possible to produce big, new features and actually produce big, new features. The focus should be placed on hiring those software engineers who have “experience” dealing with the software problem(s) you have and less about tossing warm bodies at the problem.

Great truths about computer programming

After sitting around with a few programmer friends of mine we came up with the following truths about computer programming.

  • Programming is 99% self-taught. See all that stuff you learned in that Python class? Yeah, you’re going to relearn it all when working on a real project.
  • There’s no such thing as a simple bug. A stupid mistake like leaving out a semi-colon or misspelling a variable name can easily take a week to find and fix and can cause significant loss of sleep.
  • The more code you write the more you shut up about what’s possible and what’s next to impossible. And the more you pity those newbies with that “Of course it’s possible!” mentality.
  • The language you use doesn’t matter. There’s so much fuss about which language is better for x or y. At the end of the day what matters is can you solve the problem? As a company manager, I’ll want to see a running system. Not a running (insert language name here) system.
  • Six months later, you wouldn’t recognize your own code. Documentation and comments are more of a survival tactic than niceness to whoever encounters it next.
  • Programming isn’t sexy at all. Try taking that girl home by telling her your heroic tale of saving an entire department by rewriting a recursive function to take advantage of a feature in the new server Intel chips to scale up their online orders. Then tell me how it goes.

How do Project Managers break down requirements into Stories?

A good product manager doesn’t “break down” requirements into user stories, they start with good user stories and work from there.

The whole point of using user stories is that they are how you communicate “requirements” to your development teams — by stating the user persona that you’re targeting, the task that user is trying to perform, and the goal that the user expects to achieve.

If you’ve already got a list of “requirements” then you’re not really using user stories for the purposes for which they were intended.

That said, you may start with a very large user story, such as “A new customer wants to set up an account so that they can access the product.” That story is way too big for a team to do in an iteration, if at all. We generally call these “epics” which can be broken down into “themes” and then further broken down into “stories” until we get to something that a single development team can fully complete in a single iteration. For this story, that might look something like this:

  • Epic: “A new customer wants to set up an account so that they can access the product.”
  • Theme: “A new customer wants to confirm their email address so that they know we have the correct account information for them.”
  • Story: “A new customer wants to enter an email address so that we can contact them if we have information that is important to them.”

Communicating Agile “requirements” using user stories requires a completely different perspective and starting point than traditional product management approaches.