Encosia - ASP.NET, AJAX, jQuery, and more

Technical debt is like ketchup

Short By . Posted October 15, 2012

Image by Zieak (http://www.flickr.com/photos/zieak/431730940/)

Have you ever tried washing dried, day-old ketchup off a dish? It’s not fun. What would have taken just a couple seconds to rinse off while it was still fresh can take minutes and multiple attempts to scrub off later.

Worse, the realisation that you’re going to have to deal with the dried ketchup is most likely to come right when you need to do something else with that dish the most.

As you let ketchup (and other foods) accumulate on your dishes without cleaning them immediately, eventually your entire collection of dishes is unusable.

Some dishes are more disposable than others. For some dishes, you’re eventually more likely to throw the dish out and start over with a new one than find a way to make the ketchup-spackled disaster you’ve created serviceable again.

Seriously though

One of the hardest parts of software development is simplifying and explaining it to the non-technical people who write the checks. Technical debt is one of those crucially important concepts that can alter the course of an entire company if left unchecked, but it can be incredibly difficult to clearly convey that to non-technical stakeholders.

Your negative notions about what debt is might be what a “business guy” considers productive leverage. You can just pay that debt back after the new feature makes us all rich, right? I wonder if that has ever happened?

Next time, tell them it’s like ketchup.


Interesting details on IE10’s JavaScript performance tweaks

JavaScript, Short By . Updated June 13, 2012

There’s a great article on the Internet Explorer team’s MSDN blog this week, Advances in JavaScript Performance in IE10 and Windows 8. I’ve been running Windows 8 as my primary OS for several weeks, and I must say (as bizarre as it feels to type these words), IE10 is incredibly fast and fluid. It’s almost like that first time you used Chrome after using Firefox with too many add-ons. Whatever they’re doing over there, it’s working.

The entire post was interesting, and you should probably read the whole thing if you’re a serious JavaScript developer. However, one point in particular stood out to me, regarding a new approach to deferred parsing:

The JSMeter project from Microsoft Research showed that typical Web pages use only a fraction of code that they download – generally on the order of 40-50%. Intuitively, this makes sense: developers often include popular JavaScript libraries like jQuery … but only leverage a fraction of the functionality the library supports.

To optimize such scenarios, Chakra performs only the most basic syntax-only parsing of the source code. The rest of the work (building the abstract syntax tree and generating bytecode) is performed one function at a time only when the function is about to be invoked. This strategy not only helps with the responsiveness of the browser when loading Web pages, but also reduces the memory footprint.

In IE9 there was one limitation of Chakra’s deferred parsing. Functions nested inside other functions had to be parsed immediately with their enclosing functions. This restriction proved important because many JavaScript libraries employ the so called “module pattern,” in which most of the library’s code is enclosed in a large function which is immediately executed. In IE10 we removed this restriction and Chakra now defers parsing and bytecode generation of any function that is not immediately executed.

Microsoft’s focus on real-world performance enhancement in IE9 and IE10 has been an under-appreciated breath of fresh air in the browser wars. Remember when everyone was competing to improve scores on synthetic JavaScript benchmarks instead of concentrating on actual on-page performance? I don’t miss those days.

If Microsoft would address the archaic extensibility model in Internet Explorer, I’d probably be using it to type this post right now. Given replacements for the dozen-ish essential extensions I use in Chrome, I could see myself being tempted to switch back to IE after ten years of Firefox and Chrome.

The landscape today is reminiscent of how things were shaping up just before so many of us began switching from Netscape to IE5/6, way back when. Never underestimate how fiercely Microsoft can compete and innovate when an entire division of the company commits to winning.

Facebook is retaining Instagram’s users, not acquiring them

Short By . Posted April 9, 2012

There’s been plenty of cynical talk going around about today’s news that Facebook is acquiring Instagram for $1 billion in cash and stock. One of the most salient points is the simple arithmetic on how much Facebook is paying for each of Instagram’s roughly 30 million users. With Facebook paying somewhere in the neighborhood of $33 per Instagram user, that seems fairly pricey compared to Facebook’s own valuation of roughly $120 per user.

What’s missing from that math is that Facebook users spend a huge amount of their time sharing and viewing photos. According to recent Comscore data, Facebook users are spending 17% of their time viewing photos on Facebook. Photos are incredibly important to Facebook.

Time spent on Facebook by type of activity.

Thinking of how I use Facebook and how I’ve seen others use it, I’d even make a case for the photos being a crucial part of drawing users into the remaining 83%.

Almost overnight, Instagram’s social network of photo enthusiasts gave it a solid beachhead into some 17% of Facebook’s social stronghold. Perhaps maybe even more importantly, Instagram is entirely focused on mobile (where Facebook sees its future). Maybe Instagram had no intention of ever competing head-to-head with Facebook, but I believe Instagram actually posed a greater potential threat than Google+ has yet.

Though it’s hard to fathom a $1 billion valuation for such a simple app and service, maybe that’s a reasonable price to quash potential competition to the unimaginable windfall that is Facebook. Facebook isn’t buying new users, but paying a premium to retain the union of Facebook and Instagram’s shared users and redirecting this aspect of their engagement back toward Facebook.

Targeting WebKit is not like targeting IE6

Short By . Posted February 17, 2012

There’s been a bit of controversy lately concerning the rising dominance of WebKit-based browsers (e.g. Chrome, Safari, and Mobile Safari) and the potential that we’re repeating past mistakes:

Not so long ago, IE6 was the over-dominant browser on the Web. Technically, the Web was full of works-only-in-IE6 web sites and the other browsers, the users were crying. IE6 is dead, this time is gone, and all browsers vendors including Microsoft itself rejoice. Gone? Not entirely… IE6 is gone, the problem is back.

However, I believe there’s one gigantic difference between IE6 then and WebKit now that’s being overlooked.

Microsoft put the brakes on Internet Explorer development after IE6 because they realized that they were helping build the runtime for their own competition. If Internet Explorer releases had continued at the same pace, most everyone would probably be using IE15 today and IE6 would be as memorable as Chrome 4 or Firefox 7.

Conversely, Google has a vested interest in Chrome’s ongoing success (and WebKit’s success by extension). Instead of threatening Google’s primary revenue stream, WebKit and Chrome serve to enhance Google’s golden goose. So, unlike the past situation with Microsoft, Netscape, and IE6, Google has no motivation whatsoever to shutter active development on Chrome and WebKit if it overtakes Internet Explorer and Firefox.

Does that make vendor prefixes and targeting experimental features a great idea? Maybe not. Frankly, I’m not qualified to speak intelligently about cutting edge CSS features.

What I do know is that just because the current climate seems similar to the one ten years ago, that doesn’t mean it’s reasonable to assume history is repeating.