Programmers write better programs when working under performance constraints. Compare the BBC news web site from ten years ago with it today:
http://news.bbc.co.uk/2/hi/south_asia/3392809.stm
http://www.bbc.co.uk/news/world-us-canada-25671970
2004: 55 requests ❘ 67.8 KB transferred ❘ 1.16 s (load: 1.16 s, DOMContentLoaded: 1.15 s)
2014: 172 requests ❘ 330 KB transferred ❘ 38.38 s (load: 8.35 s, DOMContentLoaded: 7.95 s)
On gigabit internet with a top-end laptop, the old site is simply better. It could use some more padding and margins, but I'm reading the content sooner, and the page doesn't jump around after I've started. Turn back the clock for a better user experience.
What happened? Did BBC's engineering team fall apart?
Try the two sites again, only this time on your phone. Again, a top-end phone on high quality wifi. Both sites are roughly as usable as each other. While the 2004 page loads marginally faster, the new page is actually smaller!
2004: 55 requests | 129KB transfered | 2.06s (load: 2.08s, DOMContentLoaded: 2.03s)
2014: 83 requests | 36.2KB transferred | 4.85s (load: 2.13s, DOMContentLoaded: 2.00s)
So BBC programmers aren't bad, they just don't know how to care about desktop user experience. Their powerful desktops are reading pages off their corporate network. They are blinded by living too far up the technology curve.
What can be done? Programmers could be given slower machines, and we could insert deliberate latency into our networks.
But these are technological hacks to approximate what we really need, which is a culture shift in software engineering. Make it fast. Internalize that concept. Live it, breath it. If it is slow, it's broken. When a program is fast, you use it more. You see more bugs. You can fix bugs sooner. It's easier to play, and discover the better program hiding inside.
http://news.bbc.co.uk/2/hi/south_asia/3392809.stm
http://www.bbc.co.uk/news/world-us-canada-25671970
2004: 55 requests ❘ 67.8 KB transferred ❘ 1.16 s (load: 1.16 s, DOMContentLoaded: 1.15 s)
2014: 172 requests ❘ 330 KB transferred ❘ 38.38 s (load: 8.35 s, DOMContentLoaded: 7.95 s)
On gigabit internet with a top-end laptop, the old site is simply better. It could use some more padding and margins, but I'm reading the content sooner, and the page doesn't jump around after I've started. Turn back the clock for a better user experience.
What happened? Did BBC's engineering team fall apart?
Try the two sites again, only this time on your phone. Again, a top-end phone on high quality wifi. Both sites are roughly as usable as each other. While the 2004 page loads marginally faster, the new page is actually smaller!
2004: 55 requests | 129KB transfered | 2.06s (load: 2.08s, DOMContentLoaded: 2.03s)
2014: 83 requests | 36.2KB transferred | 4.85s (load: 2.13s, DOMContentLoaded: 2.00s)
So BBC programmers aren't bad, they just don't know how to care about desktop user experience. Their powerful desktops are reading pages off their corporate network. They are blinded by living too far up the technology curve.
What can be done? Programmers could be given slower machines, and we could insert deliberate latency into our networks.
But these are technological hacks to approximate what we really need, which is a culture shift in software engineering. Make it fast. Internalize that concept. Live it, breath it. If it is slow, it's broken. When a program is fast, you use it more. You see more bugs. You can fix bugs sooner. It's easier to play, and discover the better program hiding inside.
If you give programmers a slow machine for development they will complain mightily and upper levels of management will replace their slow machines with faster ones (from my personal experience).
Since that doesn't work you must require the QA department to test sites on slow machines with emulated slow networks and set a standard for load speed that will bring those problems to the front.Mar 1, 2014- My takeaway from this: I'm going to grow a mustache.Mar 1, 2014
It's so easy to blame on the programmers. But here's how it often goes: IT projects are more often than not late and over budget. The team manages to launch the new site after "only" 1 month past the original deadline, and it's "only" $5000 over budget. Do you think you can convince your manager (and his manager) to spend another extra month and $5000 into optimizing the desktop site?
Giving developers slower machines and networks will make them realize the slowness, yes. But that would also mean that they would be constantly struggling to optimize things, making development slower and even later and more over budget than it already is. Most likely the entire project will then be axed by management.May 2, 2014
Add a comment...