Friday, June 25, 2010

Ignite Boulder: Morning After

Last night's Ignite Boulder was one of the better ones. It was the first held at Chautauqua's auditorium which is a great venue; though the audio was a bit off for the sparks (music sounded solid). I hope Andrew sticks with Chautauqua as a venue going forward (at least in the nice Spring/Summer months), it was nice to chill at the park before/after the event.

With increased popularity, the content feels like its starting to water down a bit. I want the edge back! Where's the heckling anymore?!? I do my part, but more often than not the ppl around me don't get it. The perils of mass mediaization; I wonder if you can ever get away from it en masse. If anyone can figure out the mix it's Andrew though.

A few of the talks struck me as particularly bad, and a few as particularly good. Some thoughts on the good ones.

Josh Fraser's talk on fear
Reminded me of Bowling for Columbine. We live in a culture of fear, and it's sad. Statistically everything's always going to be alright, yet we live with irrational fears that dramatically affect our behaviors. Why we do this is always a good question, and Josh got the numbers out there in front of us to laugh at. Nicely done.

Ryan's talk on selfishness
Should you be selfless or selfish? I've always lived my life as a selfish bastard, so I felt a little vindicated w/ this talk. Ryan's one of those rarities in life. Incredible ability to put the core of his being out there in front of everyone, and not in a lame way, rather in a way you connect with; he has true creative genius. Favorite line of the night [paraphrase/butcher]: "while trying to be selfless in trying to be what the one I love[d] wanted, I turned into something she didn't love at all because I lost my selfishness."

Ceci Ervin's talk on a trip to Poland for a surgical procedure to help/cure MS (which she has).
I'm not a sympathy vote kinda guy (back to that selfish thing), but she presented her quest in such a way that the faith and bravery simply tore through the screen and into the audience. Unbelievable journey with a happy ending. This kind of insight always makes me feel weak and useless, which then drives me to be more. Thanks for the perspective Ceci.

Sunday, June 13, 2010

Can Google's Native Client SDK Fix The Web?

Modern life owes much to the Internet. Many proverbial thanks are due to the inventors at CERN (incl. Tim Burner's Lee) and to Netscape (Jim Clark; the money. Founding engineers; the know-how) for making it accessible to all of us. A recent visit to Google's Boulder, CO office brought back that aching question for me though; is this all the Internet has to offer?

What if it never happened?
Would traditional client-server computing have been able to push network infrastructure (modems, hard-wire networks, wireless-networks, fiber, satellite) as far as the graphical browser has? If we had given it the years that the Internet's had, would we have skipped over and evolved past all the advertising, porn, and shopping that has become our network? I have to wonder if we have simply over-sold/hyped ourselves over the past decade, and subsequently distracted ourselves from the end-goal; better overall human computer interaction. The web is a complete UI/UX disaster, and has severely stunted HCI (Human Computer Interaction) efforts that can only come to fruition with deep driver/hardware bindings (e.g. Oblong - a firm you've never heard of that has the potential to change everything). We're still wallowing around inside web pages, building applications that have awful authentication/authorization models (how many usernames and passwords do you have?), and HTML5 is our latest savior?!? Please.

Getting Serious (again)
My recent conversation in the Google cafeteria challenged some base assumptions that I, and most of my colleagues, make; namely that web-apps are "it." That lunch discussion is well represented in a talk two of the key engineers gave at Google I/O 2010; Programming the web with Native Client SDK". When we were talking, what was initially described to me was something I could neatly, and conveniently, fit into today's browser plugin APIs. "Why not just use NPAPI; why re-invent the wheel?" I asked. I got a response that only someone with the know-how, and the resources could give; "because this [web as we know it] can't be it." I left skeptical, but it's been a month or so, and I'm there.

We'd be nowhere without the tubes that have been built. From a gazzillion miles of various types of cable/wire being laid all over the world, to IP/HTTP ubiquity. However, consider them a simple, yet crucial, layer in the client-server software model stack. Sure it's taken us 15 years to build it, but what if you chalk it up as "done." What's the next layer in the cake diagram that you'd pursue?

If we'd had this layer complete 15 years ago, the kings of client-server software at the time (Microsoft and IBM) could have started building highly distributed applications then, as opposed to trying to do so now (IBM quite successfully in more of an industry consultancy role, and MSFT arguably flat out failing at it). With Native Client, Google is trying to answer the question of what should software look like now that the connectivity layer is "done?" It's a cool question if you think about it and are able to extract yourself for a moment from our day-to-day web-app construction, and browser engineering realities; we have a hard time seeing the forrest from the trees.

It has a very long way to go, but a new way of executing "native" code through our "tubes" could open the door to a new generation of software. One that can harness the power of our hardware and the most important part of the Internet, namely the "tubes." While a train-wreck, recall the confines Microsoft tried to break out of with Microsoft Bob; knocking down the four walls of the traditional rectangle window managers that none of us exists without. Imagine networked software that can talk to your hardware to obtain identity information (something that requires a hardware component; you). These are things that we shouldn't be dreaming about, they should just be.

While Google's Native Client SDK goals seem audacious, they are also admirable, and if there's one company out there right now that has the power to pull something like this off, Google's it. Good luck.

Monday, June 7, 2010

Development Process

Tonight I was asked some high-level questions about development process. I wound up responding w/ enough material that I thought I'd share the thoughts here for broader consumption.

Hey guys,
Please feel free to ignore this email but I'd extremely appreciate some advice if you have a couple of minutes. I am trying to compare best practices for teams over 10 programmers to determine what software development methodology has been the most productive for your company but at the same most fun for your team. If you have time I'd appreciate answers to the following:

1) Software Development Process used (i.e. Scrum, XP, custom)
"agile" (no scrum)... weekly iterations/sprints (no standup). have driven/done xp (pair programming mix) as well; I'd only go this (xp/pairing) route again if I were in a more supportive ecosystem (e.g. SF).

2) Do you track # of hours programmers work in a project?
never. bad idea IMO.

3) Do you have a QA team, if so how many?
no. though I've considered one or two QA folks... it'd definitely be nice to objectively do white/black box testing outside of dev. we're pretty close to TDD, so we've convinced ourselves we "don't need it." I go back and forth.

4) How often is your release cycle?
we deliver code to production once a week.

5) Who is allowed to deploy code into production?
we rotate who does the deploy (everyone on the team, including me, is capable of doing it). we run a shared responsibilty/exposure shop in order to reduce/eliminate the "john's the only one who knows that code/process" scenarios. my general philosophy here is if you're not hiring engineers that you don't trust well enough to do a deploy... you're liking hiring the wrong folks.

6) What project management tools do you use? . in the spirit of agile... we're very light on process/tools. never document something in more than one place (e.g. in the "story"), and even then be light.

7) How accurate are your release predictions?
eh. having tried (as mgr and individual contributor) everything under the sun... I no longer believe numbers folks toss out ("we're 90% on time" etc). I've found everyone's (mine included) numbers are BS, and if you dig into what actually transpired after the release... enough corners were cut, enough brilliant engineering ideas employed, and enough requirements were relaxed during the release cycle, that you never end up with what you started with anyway, so the A to B comparison and judgement of "on-time" is never valid. your mileage will vary though. it all comes down to the "unit"... the "team"... their cohesiveness, experience working together and trustworthiness amongst eachother. that said, if you handed me a green teem of folks that never worked together, I'd drive it agile-style with one to two week iterations/sprits (and production deploy) cycles with goal-level commitments (e.g. team committing to having x y and z done by date 'a'... and working as hard as they can to meet that commitment).