Speed and Scalability

If you’re working on smaller projects with no notable load, “popular” languages such as Ruby, PHP and Python are great; After all, they are optimized for developer productivity rather than runtime performance, and in 99% of all cases this is fine. This is the main reason they’re so popular in the startup scene, as they enable extremely rapid feature development as a business evolves to find its place in the world.

At some point, however, a designed system must perform at scale, and as most detailed examinations such as this one show, not all languages are created equal. Delivering software at that level in a language that has a poor performance profile changes the discussion entirely: If your system chokes, you lose business transactions, customer confidence, and reporting data, all of which translates into money. In short, the argument stops being about the salary of one or two additional engineers, and more about the reliability and maintainability of your codebase.

Not only have years of optimization made it a very reliable and performant platform, the religious arguments about What Is The Best Tooling™ out there have been had and are mostly over, with configuration winning out over convention every time. The IDE’s support it, Continuous Integration Environments support it, Unit Testing frameworks exist and are very mature, and even though the code itself is extremely verbose, shitty Java will still run faster than shitty Ruby. Mind you, the study in the post linked above was done several years ago, and I’m quite certain that the various languages have improved since, however given the lack of community trumpeting about oh-look-we-finally-beat-Java, I’m going to take that post as mostly-still-accurate.

B2C vs. B2B

The second big shift that happens at scale is a shift from a consumer-based business to a service-based business. Don’t get me wrong: Consumers are important, however onboarding more consumers is a linear function, and usually not a very steep one. Onboarding businesses to your platform, however, is an entirely different beast, as each new partnership could bring orders of magnitude of extra load to your system. Is this a provisioning problem? Yes, yet with it come a whole new set of problems: Will you need to provide authentication integration with their corporate LDAP system? Will you have to Whitelabel your service? Will you need to provide API support? A dedicated and/or isolated data cluster?

To be fair, these are language-agnostic architectural problems, ones which encourage a clear separation of UI and API layer, forcing all business logic into the latter. Websites in this system are simply UI clients and serve no purpose other than making the API human-friendly (not to be discounted- UX is super important).

Now that the UI is simply a facade, does it really make sense to render it on a server before sending it back to a client? Let me illustrate with an example:

Consider a website written in PHP that consumes an API.

1. I visit this website
2. The Application Server makes an API call
3. The API returns the data
4. Application Server Renders the data.
5. Browser renders the HTML
6. I get my html

Now consider a website written mostly in Javascript that consumes an API:

1. I visit this website
2. Browser calls the API
3. The API returns the data
4. Browser renders the HTML

See the difference? In the former case, you’ve got two times as many network transactions (added points of failure), and the additional cost of maintaining an application server. In the latter case, you can host the files on a glorified hard drive (S3 for instance) and are talking to the API directly.

But Javascript Sucks!

It really doesn’t: Javascript is an amazing, powerful language that is hamstrung by browsers, an outdated standards body, and a lack of a unified toolset.

Thankfully, browsers are starting to come around (Chrome at the lead) and implementation difference are starting to be eroded. Most of the javascript libraries out there (such as JQuery) don’t seem to have caught up to this fact yet, and are still rooted in the philosophy that they can only work for what works everywhere – no worries, they’ll evolve soon enough if their communities will let them.

The current arguments between the WhatWG and the W3C are obvious to anyone in our industry, and different business philosophies between browser vendors make sites like caniuse.com an unfortunate necessity. Add to that the never-ending political maneuvering in the ECMAScript standardization process, and javascript will forever be a bastard child of 5 different parents each telling it to follow a different career. Having said that, Google has successfully used Chrome as a strategic tool that established a de-facto standard, forcing other vendors to catch up.

Javascript tooling is still in its infancy, and many tools out there have not yet grown beyond themselves. Take, for instance, a unit testing framework like QUnit that is sadly dependent on JQuery, or a functional testing framework like Lebowski which is inexorably tied to Ruby and Sproutcore. Furthermore, many frameworks are differentiated by philosophical differences (take QUnit vs Jasmine for instance) which muddies the water even more. Lastly, even with a plethora of tools, nobody has managed to wrap it all into one single, cohesive whole that combines Formatting, PMD/Linting, Unit Testing, Functional Testing, Documentation and Optimization.

However… the tools are (mostly) all there, individually. JSDoc has become a de-facto standard. Google’s Closure compiler is mostly platform agnostic, drawing most of its cues from JSDoc. Jasmine could be your one-size-fits-all Unit Testing framework (assuming you like behavioral testing), and JSTD is a powerful testing framework that can be used for either unit or functional testing (It’d be even more powerful if the various browser runtime engines could be run headlessly like Mozilla’s Rhino). All it takes is for some enterprising individual to put them all together.

1- They don’t think of themselves as rock stars.

Arrogance is perhaps a key requirement in being an entrepreneur, but overconfidence will drain your cash pool faster than hookers and blow.

2- They have a proven track record of multiple shipped products.

You don’t want a hotshot kid out of school, you want a seasoned professional, preferably one who knows how to write applications for the industry you’re trying to reach.

3- They care more about frameworks than plumbing.

Unless you’re trying to design a complex new mathematical algorithm (in which case you should probably be partnering with a university research lab), you want someone who can grasp a system rather than a method. If this guy ends up in deep technical discussions about the optimal way of implementing a sort, you’ve got the wrong guy.

4- They’re not willing to work for free

Risk management and strategic thinking is key to long-term project viability. If you have someone willing to work for equity, they’re willing to take risks with your payment processing gateway just as easily as they’re taking a risk on you.

5- They believe in development process and best practices to speed up their work.

The last thing you want is someone who’s trying to reinvent the wheel. Mind you, this also likely means that the first two weeks or so of development you’ll see a lot of development support tools get set up and used before code actually starts, but that’ll give you time to get your documentation in order.

6- They have a positive attitude.

If someone bitches, they’re looking to blame themselves. Instead, you want them to identify their concern as a problem they can solve.

7- They get uncomfortable when you ask about their social life.

’cause, well, currently it’s still socially odd to prefer coding on a saturday night.

8- You don’t want Alphabet/Acronym soup in their technical skills.

Lots of languages means little depth in each, and depth = speed. Pick a serverside language (PHP, .Net, Ruby, etc), pick a database (MySQL, SQLServer, Postgres, etc), and pick a frontend (Flex, Mootools, JQuery, etc). Focus on that. If a dev has only a few languages this does not mean they’re stupid- it means they know how to focus.

9- They’re involved in the community.

Speaking, attending, whatever, you need to make sure their technical skills don’t stagnate, and that they’re willing to accept ideas from outside.

10- You respect them

Respect means you are willing to listen when they tell you you’re full of it, and that’s key in a partnership. You’re not looking for a monkey you can put in a corner who can bang out some code- you’re looking for a partner who’ll act as a technical sounding board.

So now I have this question: What makes for a rockstar business partner?

Lets take Twitter as an example. Their service statement is, in a nutshell, “We let you microblog”. They don’t do it particularly well, their online interface sucks, their features are extremely limited, and the service goes down so often that the “Fail Whale” has entered the colloquial as a term unto itself. And yet their users remain loyal, the service continues to be used, and it’s probably the most popular microblogging service out there.

Why? Realize that 80%+ of twitter activity goes through their API, not the website. In other words, the guys at twitter have opened up the doors to the kingdom and allowed the community to decide how they wish to consume the service. That same community has risen to the challenge, providing a plethora of applications, widgets and plugins that allow people to consume and update twitter where and when they want to.

Lets take a closer look at what actually happened here: Twitter provided an API… and let the community (whether individuals or businesses) suck up the cost of developing use cases and interfaces, do usability testing, write requirements and eventually write the software. In short they just made someone else pay for the entire involved and expensive front-end development process.

Not only that, but they also neatly sidestepped the need to perform strategic market analysis to manage their own growth. Rather than focusing on meeting the needs of a single segment (and expanding from there), they boiled the service down to its absolute essentials and let each segment figure out how they want to use it.

This approach isn’t particularly new. AOL IM and Jabber have been around for a while now, Google and Yahoo have been making their services available for years now, and most of all the world wide web itself is… well, a communication platform built on the premise of a server/client relationship.

The key is integration. There are so many services, websites and widgets out there today that only the truly exceptional will be able to stand independently on their own. All the others are fighting for search engine placement, social tags, advertising and community buzz to promote themselves, but are never likely to hit the big-time unless they can integrate themselves into their user’s pre-existing day-to-day activities.

Wouldn’t you call that the value statement of any new company? “Provide a service that improves a users day-to-day activity so dramatically that they can’t live without it”. Whether this is done via process improvement (Make a task more efficient / less frustrating) or activity enhancement (Now you can tag your pages while you surf them) doesn’t really matter, because the core task remains the same.

My favorite example of this phenomenon is Firefox, because it provides a platform where users can customize their browsing experience with all the ancillary services they want. Plugins exist for del.icio.us, livejournal, myspace, gmail, etc etc etc- all tasks and activities that may not be directly related to the core browsing activity, yet provide a sufficiently compelling experience enhancement that they’ve become part of day-to-day web surfing.

So in summary: If you’re providing a new service, put some serious thought into building an open API. If your services and your data (’cause that’s what it boils down to) are compelling enough, you stand a good chance of having the community take care of segmentation, marketing, and implementation.

src ="http://www.practicalflash.com/AIR/Installers.html"
width="100%"
height="200" style="border: 0px none #000000">

Practical Desktop

Practical Desktop appears to be a simple timekeeping application, though in reality it’s an open source widget framework that allows pretty much anyone to build a deployable block of functionality that can start interacting with other widgets. The wrapper’s there for you, go nuts. The source is here

From a personal perspective, I use it as a beta and explorative sandbox, because there are a lot of interesting things coming out in the near future that I’d like to offer some guidance on development best practice, and to do so I will have to figure it out myself first. Rest assured that the widgets I build will be functionally complete, though perhaps limited in feature support.

Pandora

The Pandora Desktop application is really just a customized webkit browser that’s hardwired to the Pandora mini player. I’ve fixed the application so minimization works in Windows, and expanded it to include the player’s html wrapper as well. The reason I did this is because Pandora’s a free service, and I’d like to make sure that I’m not ripping them off by stripping out the ads. Optimally I’d like to help them convert their existing player to AIR, but until I have free time (or they pay me ) that won’t happen.

First of all, in an effort to deal with blog neglect I’ve shifted my usual authoring time to before work rather than after. Afterwards there are simply too many distractions- mental, physical and… ahem… social for me to really get focused on my thoughts and get them down. Whether I can keep it up is anyone’s guess, but for now I’ve got a nice cool morning, a full battery and a patch of sunshine to write in. What else could you want?

Secondly, we had our annual reviews here at work recently, and by all accounts I did pretty well. I had to go out and get a short-term prescription for insulin to deal with much of what was said during the review, and after a rather superfluous compensation discussion (what am I going to do, argue about a raise? Oh no! You’re giving me more money! Whatever will I do!) I’m now happily sitting on a modest increase. Given that my last three places of employment didn’t really believe in “raises” per se (one of my coworkers was fired because she asked for one), it’s a welcome change.

Thirdly, we released a bunch of new content for my project, HP Print Studio yesterday, which marks our first major push for international content. Included was pretty much all of south america, so in the end it was only two new languages (Portuguese and Mexican Spanish), but given that every country can customize the application down to the last background image, rolling out those 18 new countries was no small feat.

Of course, doing a rollout of that scale showed some of the cracks in our localization strategy, so I won’t lie and say it went smoothly. I was at work until very late on wednesday resolving last minute inconsistencies, and had to give up my weekly salsa lesson/social for the project (which I find amusingly ironic- latin america, salsa… get it? . Having said that, I now have intimate knowledge on what’s broken and how to fix it, and an initial cost/benefit analysis means we might even be able to charge the client for it (though at this point I’m doing it simply for my own peace of mind).

Lastly, we had some… unfortunate downsizing at work. I won’t go into the detail of who, how and why, just to reassure my readership that I wasn’t affected (well, other than the shell shock). The reason I brought it up is because, having gone through two business evaporations, two acquisitions and a few other unfortunate staffing events, I don’t think I’ve ever seen this kind of event handled so well.

How do I mean that…

First of all, most of my downsizing experience has been reactive, in that a business had to suddenly adjust to an unexpected market adjustment or ‘catastrophe’. Fact is that most of those events could have been predicted with a little foresight, and reductions came as a surprise to the majority of the organization- even HR in some cases. My takeaway from those was that the business is poorly managed, and that there is no real driver at the helm. In short, that the only direction the business had was as a result of momentum.

In contrast, everything about yesterday’s event seemed strategic, well thought out and considered, and ultimately necessary. It was done because of the recession- I won’t lie there – but it was also done because of a whole host of other (undisclosable) conditions had been factored into the decision process. My takeaway here was that not only is there a driver at the helm, that driver also likes to to pull into a garage every so often, adjust the mix, check the fluids, clean the filters, refill the nitro and get a new set of fuzzy dice for the mirror. In short, someone who knows exactly what’s going on under the hood.

Having said that, if any of my former coworkers would like me to use my burgeoning network within the digital creative community to help connect them with potential opportunities, let me know- I’ve made some contacts through the Adobe User Group that may prove valuable.

The catch though is that this next month, at least from a work perspective, is really going to suck. I can’t really go into the details, but in a nutshell all the things on my plate are coming to a head NOW, and some of those things are interfering with the others due to some legacy processes that we’re still trying to scale. Given that I work in the Agency World™, process improvements don’t happen unless you have an ROI argument or a client willing to pay for it. If it’s not built right the first time, chances are you’re stuck.

Thankfully, the experience is invaluable, and I’ve learned some absolutely amazing things about building large scale multi-platform deliverable applications. Next time around much of this won’t happen, though for the time being I’m going to have to find some of my own time to throw at the issue so that in the long run I can have some peace of mind and free time.

Unfortunately, that means that Dance has effectively fallen off my radar. I know I love to do it, but when I can’t guarantee that I’ll be free for my 8PM lessons on a regular basis on account of work, well, I can’t really do anything about that. So in order to make sure I don’t lose the hobby altogether I’m doing a measured pullback and returning to my roots and origins: Salsa. As much as I hate to step away from Swing and Tango and Ballroom and all the others for the time being I’m afraid I just don’t have the time.

Scaling that back, however, has opened up a surprising amount of time for other things, time that under other circumstances would have been spent in transit or in support of my usual posterior shimmying. For instance, my apartment garden is flourishing, my Bonsai are crawling out of their pots, and I’ve started releasing some code libraries again over at Practical Flash. Plus, of course, I’m making cheese.

Having said that, I’m looking forward to this next week. On Monday I’m speaking at Flex Camp Cleveland on “How to build your first Flex Application”. I’m pretty nervous about that one, actually, since I go on right after Ben Forta . Yes, that Ben Forta, the guy who’s pretty much the face of ColdFusion for Adobe. Furthermore, on Friday and Saturday I’ll be volunteering at the Cap City Classic. The original plan was to run the Half Marathon, but splints stopped my training, though I’ve just gotten a small post-work running group started to get me back up to some acceptable mileage. Given that, I’ll be running back and forth from my road marshal position on saturday, which nets me about 8 miles and change with a nice long break between the two.

Then in May, I’m taking a break. I have 2 weeks of “vacation” scheduled, one for the Adobe Community Conference in San Francisco (Which neatly coincides with my birthday. Hint Hint), and then a week of careless lounging at the beach for memorial day. I still have to find someone to help me run the May Adobe User Group presentation night, but I should be able to get that done fairly easily. I hope.

Ahh well, back to polishing off my presentation, and then I’m off to go enjoy the nice weather some more.