Wednesday, May 30, 2007
Alt Framework Hackfest
We here at IT appreciate the diversity of web frameworks and methodologies that have arisen or gained popularity over the last few years, and we've had our filthy paws over and into a few of them. Some we like more than others, and some of us are more vocal in our advocacy than others.

What I'd like to propose to my co-conspirators here is that we have a little hackfest with some of our favorite web frameworks over the next month or two, and see what develops. I'd propose some similar goal to be developed in each framework, but that might be too constricting. I'll let you guys weigh in before we kick it off, just to get consensus, but I'm guessing spinning out a blog in each shouldn't be too hard, and it would allow for embellishment as the frameworks and time allow. (note, I know we all have crazy schedules right now, which is why I think a month or two sounds good... correct me if I'm wrong)

Frameworks I'd like to see included:
I think it would be great to show some of these frameworks side by side, performing similar tasks. Sure, the validity of the comparison would be limited by the scope of the project, but I think it would be nice to see functional apps from each, if we're going to keep hearing the same evangelism about Framework X or System Y every damn time I log on.


Labels: , ,

Google Gears
Google is at it again, this time maintaining its position at or ahead of the curve with Google Gears.

What is it? It's the latest in a great trend toward allowing for creating hybrid web apps that can run on- or off-line. Google Gears is by no means first to the party, however. Joyent was out the gates early with Slingshot, which we had the pleasure of getting a look at up at RailsConf. Adobe is also trying to get in the game (from an admittedly different angle) with its work on Apollo. Add in to this mix the browser-as-dev-platform path that Firefox 3 might be taking, and we can see that the world is moving very rapidly toward a synchronizable, online/offline world.

So why do we care about Google Gears? I'm sorry, that was a stupid question. We care because it's Google, and they have the intellectual resources to really solidly address this path, coupled with their penetration into just about every technological market. Also, they're following the grand tradition of their code projects, and opening a lot of code base for use by developers. The APIs are documented and available, and they're encouraging devs to play with the beta.

Gears provides the following basics, as quoted from their site:
LocalServer LocalServer
Cache and serve application resources (HTML, JavaScript, images, etc.) locally
Database Database
Store data locally in a fully-searchable relational database
WorkerPool WorkerPool
Make your web applications more responsive by performing resource-intensive operations asynchronously

This should be enough for any web app developer to get off the ground and running, building relatively responsive RIAs... on the desktop.

Ok, enough drooling over docs. I'm going to go dig into it.

I'll probably post back later with impressions, but feel free to throw your comment in, too. I'd love to see how this is responding with different frameworks and on different platforms.

Labels: ,

Tuesday, May 29, 2007
Sunk Cost - Fallacy and Dilemma
First of all, I think it's pretty funny that the first substantial post here is me, talking about project management stuff, but it's true.

On to the good stuff:

Sunk Costs
The definition of a sunk cost is simple, but with some subtle points.
Sunk costs are the unrecoverable past costs of an endeavor.

Buy a sandwich and eat it. Sunk cost: sandwich price + time spent.

Buy a book, read it. Sunk cost: Difference between the retail price and the resale price, plus the time spent.

Now that that is out of the way, we can talk about why they matter.

Sunk Cost Fallacy
This is the formalization of the old adage about not 'throwing good money after bad'.

Basically, people have an irrational tendency to count sunk costs when they make a decision. This is pretty obvious to see in the tendency to never quit on a failing project, even if it's the overwhelmingly right thing to do.

As wikipedia says, you don't see many half finished bridges.

Sunk Cost Dilemma
Here's the really interesting part: due to sunk costs, always doing the right thing (in a naive setting) can result in failure.

Say you estimate a time and date for a project, sign the contract, and start work with the expectation of plenty of time and resources.

Midway through, your star takes sick. You have to decide whether to keep going or pay someone else to finish it. You figure there's still time, so you keep going.

Now, what's the right choice if you run into another problem? If you look at it naively again, odds are good you'll keep going in hope of that payout, even if you'll lose a little money.

The right answer to this problem is twofold: First, you assess the likelihood of the outcomes, and secondly, you take into account possible future costs of each outcome.

Anyway, to relate this back to the realm of technical things, this is one of the foundation principles of Agile/Lean methods: the more risk and the more competitive the market, the shorter your feedback cycles need to be.

I see this all the time, with feature creep and bloat. Once you build it, it's a sunk cost, whether or not it's at all useful to anyone.

In many cases, the rational answer to feature creep and bloat is to throw many things out or start over, but people hold on to the existing features because they think the money spent on them will be 'more wasted' if they are removed.

Labels: , , , ,

Monday, May 28, 2007
Fried Toast
Since the title of the blog is Illicit Technology, I thought I'd give my favorite example of rebel engineering, a spidercar from Burning Man.

I was actually just out of sight when this was shot, off to the right, about where the blog sidebar is.
Frist Poast
Hi all, first post on the new blog. Hopefully this will be a blog about tech and related idiocies.