Substituting MVE for MVP: why you shouldn't want your team to GSD

If you've been paying attention to web development or UI engineering, or whatever you're calling it these days, maybe, just maybe, you've noticed that we have a crisis on our hands.

It started out simple enough - we were notified that process is killing developers' passion - and we were encouraged to adopt one of the myriad Agile methodologies. When our productivity didn't soar through the roof, we revisited the Agile Manifesto to make certain we were doing it right and we loaded tools to help us "innovate faster". First it was jquery (which supplanted prototype, yui, and others) and bootstrap (or foundation). When those didn't work, we added CSS preprocessors like less (or sass) and we added frameworks like angular. With still only minor improvements we switched to templating with react, and state management with redux, and the cycle has continued. The result of that is that the weight of pages keeps increasing (more on this a little later), and broadband speed struggles to keep up (but fails as it only grew 25% in 2012 and 29% in 2013), and mobile speeds - even LTE speeds - which are increasing at a faster rate than broadband still lag behind considerably, especially in the US.

The argument, in the development world, has been that time-to-market is the most important factor and that by abstracting out the more common functions - like grid layouts and common interaction patterns - we speed time-to-market. In traditional terms, where software development is defined in terms of the "three-legged stool" - development speed, development cost, and development quality - we would say that the emphasis has been on development speed, or velocity in the Agile world.

"But wait," the proponents argue, "by increasing speed we've reduced cost and by introducing the development tools we've improved quality".

Unfortunately, that reasoning is not always true. First, it misses the measures of quality that take into consideration how apps are developed - for example, how well an app that uses [insert the library flavor of the day - such as Angular or React - here] runs in an agent that is not running JavaScript or how well an app works with accessibility software and devices. It misses the measure of quality that considers how machine-readable (and therefore searchable) documents are.

Second, in my experience, faster development is seldom better. One of the facts people seldom understand (or perhaps seldom remember) is that software development takes the amount of time it takes. Even though all of us are poor at estimating development tasks, as Dan Milstein explains in Coding, Fast and Slow, we still insist that artificial deadlines be met as we try to squeeze every last dime of profit from the rock.

Here's a news flash, though - it just doesn't work that way - or at least it shouldn't - and developers know it. It may be buried deep beneath the sediment of ease and lie under layers of pressure that can turn coal into diamonds, but it's there - and occasionally it rises to the surface and we see sentiments like these...

Why did it take 2 weeks to write 200 lines of code? Because I had to write 1000 lines of code to learn which 800 to throw away.

@arclight (1:03 PM - 6 Dec 2014)

You don't pay engineers to write code, you pay them to understand subtleties and edges of the problem. The code is incidental.

Ted Dziuba

The avenue of thought that emphasizes development speed also misses a couple of larger issues, because here's the thing - writing software requires the engineer to understand the problem (or use-case) so thoroughly they can tell a machine how to solve it...not another person who has a vast array of associated bits of knowledge floating around in their head they draw upon - a machine that sees everything as either 1 or 0 and can only add and subtract. (This is another reason why brain-drain can kill your organization.)

What we (collectively as an industry) have done by prioritizing development speed over quality and cost is effectively said "simplifying our developers' job is more important than our users' experience" - and while that may be valid business decision, we may not like the look of that sentiment in the light of day. Unfortunately, this is exactly where that road leads every time we add another plug-in or third-party widget.

As I said, I've been developing software for a very long time...longer, in fact, than many of my colleagues have been beyond the age to watch Sesame Street, and longer than more than a few of them have been alive. It's nice when someone wants your job to be easier, but it's not necessarily better - it's not even necessarily better for you.

About this time someone usually points out that they use this prioritization of speed in early iterations and will "go back and fix" something in later iterations. "After all", they say, "we're trying for the MVP. This is supposed to be a skateboard, not an automobile." I will climb out on the branch and say "this sentiment is nonsense". As an organization you have already made development speed the priority, and nothing, nothing is faster than already completed...and that doesn't even consider that changes made after deployment are 10x as costly. If you want to build a car, you don't start by building a skateboard. You start by building a car...probably a really bad one if you're cobbling it together one piece at a time from parts someone else built. Making development speed your priority has changed your MVP to MVE.

We often see this approach when people say "let's make this 'responsive' - everyone is using mobile", without ever considering the ramifications. "We've used bootstrap", they reason, "and everything is in a grid so it won't be a problem". Or "oh, we're seeing an uptick of widget sales in that country, we should localize to convert those leads to even more sales". Or even worse, near the end of the project someone in senior management sees the latest court case that's forcing a business to follow accessibility practices after years of thinking that "blind people don't see web pages" (don't laugh, a candidate for a UI engineer position actually said that in an interview) and they start to worry about how they would pay the millions of dollars if they were sued.

These three requests are then taken to an engineer, who looks at the code and the beautiful mobile designs their designers have produced, how the system is built with one dependency on top of another, and how those really useful third-party tools were used, and shudders with a moment of panic as she realizes just how much work will be required. At this point, the engineer usually has flights of fancy and suggests they build an adaptive site or throw away their "prototype" and that they build it right - which management sees as duplication of code and work and realizes that's not fast development...unless they can re-use code - and the cycle repeats.

None of those things - mobile optimization, accessibility, or internationalization - are add-ons; they must be built into a page from day one. And all those "tools" that are separating you from these critical activities in increasing your development speed are killing you. Even worse, they're killing your users too. Want proof? Here's a clue.

Average Kilobyte Weight of a Webpage by Technology (EOY 2012 to EOY 2016)

	2012	2013	2014	2015	2016
HTML	54	57	59	66	52
CSS	35	46	57	76	79
JavaScript	211	276	295	363	415
Images	793	1030	1243	1443	1623
Flash	92	87	76	53	0
Other	101	205	223	261	97

If this data is not concerning, it should be.

You're probably asking why this should be concerning - after all, isn't page weight part of the price of progress with all those new tools? And since a 4G connection - which is about the same as cable speeds - can send about 1MB per second down and since data plans typically only cost around $ 0.02 per megabyte (using US average data from 2015), even though we've doubled the page weight in 2016 compared to 2012, that's still only costing a user about 4 cents and taking about 2 seconds, why should this be a problem?

Here's the reality check. Those numbers are for US-based connections and are very fluid. A slow 4G connection can take ~2 seconds per megabyte, and it's still 10 times faster than 3G. No matter, you're only in developed countries, like Europe...where 4G availability may hit US-like numbers in places, but generally hovers around 50 percent (see https://opensignal.com/reports/2016/11/state-of-lte for more data).

As nice as all those numbers are - and let's be honest, when I started writing for the web we were still connecting at 2G speed so we're literally talking about them being 100 times better than they were - they're still no match for users' impatience - impatience that causes a mere 160KB of additional data to increase bounce rates on mobile devices by 12 percent. 160KB.

Those tools you're using to increase your development speed...they're costing you. You may be saving hard dollars in developer salary (though that's far from certain) but the soft dollar cost in lost revenue is adding up, and even worse, it's not even revealed in a WSoD - it's all hidden.

At this point in my posts, I usually sign off by saying "happy coding", but this time that just doesn't feel appropriate...so I guess it's just a "there you go" instead.