Steve Yegge posted a must read transcription of a talk he gave at Stanford on dynamic languages. On the last question of the day he gives a great plug for Adobe’s Evolutionary Programming model and ECMAScript Edition 4 (ECMAScript Edition 4 was the basis for ActionScript 3, the language of the Flash Platform).
If you’re a language geek or just want some ammo for your “ActionScript isn’t just a toy” speech that you have to resort to periodically, you’ll want to read and reference this talk.
Twitter has always seemed like one part silliness and two parts vanity. I’ve just never seen the value in it (I blame my advanced age). However, I’ve been more inclined to jump in as a listener of late. I don’t know what changed. Maybe my multitasking capabilities have just improved enough to add yet another signal into the comm channel. Maybe I’m just becoming a wannabe 30 something hipster. Anyways, I finally took the plunge last Friday night and quickly reeled in my first high value tweet from coworker / friend Betsy Weber who noted that, “Community Server used Jing to make screencast demos at their Hack-A-Thon event.”
Now, its possible at some point in the future I would have received an internal email from Betsy with this link, but timing is everything. I would not have written this post if I had not received the message when I did and had a bit of personal time to write (yep, I call midnight to 3 am ‘personal time’). The point is that it looks like Twitter can be a sort of early warning filter as well as a place for social banter, networking, etc.
Were there other reasons for my caving? I’ve noticed that some of the people I’ve listened to inside the Adobe channel are much more active inside of Twitter and this activity has been sustained.
Then there was the bomb shell from JD that he was thinking of abandoning blogging for Twitter. I’m actually pretty discouraged by this given his importance to the community as a voice, listener and filtered aggregator. I don’t believe the short form microblogging Twitter offers up or the awkward access to historical posts is an ideal narrative, but I guess I need to just get over it and roll with change.
Scaling is not my thing, but Greg Linden continues to be a great source to poach from. His post on Facebook’s database architecture included a link back to a video presentation of YouTube’s approach to scaling during their buildup.
There’s lots of good info here, but I was struck by a couple of things:
Small teams of talented people can accomplish amazing things in short amounts of time. In my mind the challenge for software development companies is to put together these types of teams and then figure out how to get out of their way. The amount of easily accessible info provided by the Internet has turned the world upside down in a way that mainstream software development hasn’t really figured out (information access = broader and deeper depth of knowledge for cross disciplinary teams).
Heat and pressure make diamonds. The YouTube team didn’t know what to expect or have all the answers in their pockets, but were willing to aggressively tackle the challenges. There’s a point where people fracture under pressure, but if you never put yourself in challenging positions you miss out on what you’re really capable of as an individual and a team.
After watching, I was rifling through some of Greg’s past thoughts on scaling and found the nugget above about how often you should push code on the web. We’ve being playing around with an *agile* SCRUM development process at TechSmith, but there is a ton of discussion / disagreement about how frequently our web dev teams should be pushing code. Do you push during the course of the sprint, at the end of the sprint or quarterly?
Lots of questions arise if you’re pushing frequently. How do you ensure quality? Is it worth the risk? How do you market changes and upgrades to the site when change is constant? I’ve waffled a lot on this topic. My web dev roots tell me fast and furious updates, but after 2 1/2 years in the commercial software world I’ve gotten cautious and felt like a web product should only really make major pushes quarterly. It’s hard for the organization’s other pieces (support, marketing, sales) to keep pace when change is so frequent. The question is, have I become tainted by the long cycle feature slogs of desktop development and lost my way?