Eagles do the time warp again

In the first day of the 2008 NFL draft, the Eagles moved out of the first round for the second straight year and used their draft picks on: a Brian Westbrook clone from the 2007 draft, a slight but blazingly fast kick returner, and another energizer bunny style defensive tackle.

I actually love all of these picks. I love Lorenzo Booker. It's a little bizarre to functionally use a draft pick on someone from last year's draft, but think about it. The Eagles had one Brian Westbrook. Now they have two Brian Westbrooks. Awesome.

I also love DeSean Jackson. The Eagles most glaring need last year was... special teams. Last year the special teams were terrible across the board. So they signed a bunch of role players that excel at special teams and they got a kick returner that runs a 4.35 40. Ka-ching. That's the sound of Tom Heckert earning his paycheck.

Plus, everyone is overreacting about the O-line and wide receiver. They have talent waiting in the wings. Justice and Baskett and Avant haven't fully gotten their chance, yet so don't count them out.

Nah. The Iggles are doing awesome. My only concern is that the Considine can't stay healthy and that there's still some dead weight on the roster in Howard. It's time to show him the door.

Event.on is making my spider sense tingle

I've been using the YUI libraries at work on a new project and I'm vaguely dissatisfied with the way event listeners are attached using YAHOO.util.Event. I think I have a different way that could be better, although I haven't tried it myself.

Instead of passing the function, the arguments and the scope separately, it might make more sense to pass an inline function that wraps the function call and makes sure that the scope and arguments are correct.

Instead of:

Event.on("elementId", function, arg, scope)

You would have:

Event.on("elementId", function() { scope.function(arg) });

At the very least, the latter seems more flexible to me. Maybe I've been reading too much Jon Resig.

Sakichi Toyoda and Tiny Thoughts

Joel on Software the other day had an item on Sakichi Toyoda. After reading it, the fact that I hadn't been introduced before to Toyoda's "5 Whys" struck me. It's a process for understanding that is both simple and elegant, well suited towards many tasks. It's not deterministic per se, but for the record, determinism isn't always the hallmark of excellence.

So why hadn't I been bludgeoned over the head several times by this awesome? Why hadn't it been screamed from the software engineering rooftops? And why is it that we concentrate so much on complete and multi tiered methodologies for solving development problems but not on simple tenets? I am as guilty as any. But I wish that there were a set of simple processes that would cover most of the bases. Something in the mold of the "5 whys". Something like design patterns, but applicable towards solving problems in creating software rather than the implementation of software.

Most of the methodologies that I have seen seem to fall apart through poor implementation. Agile is often poorly implemented, just like more traditional methodologies like the Waterfall. But maybe we don't need a whole big process. Maybe we need a bunch of tiny processes that can be woven together into innumerable shapes. I see Joel working in this vein, as are the people over at 37 signals. Both books are among the best that I have read in software engineering. But while both utilize this tactic, there does not seem to be anyone creating a unified list of tiny processes, and how to move forward using them instead of more involved methodologies.

Simple means simple

Today’s recurring theme of the day is that there is a problem with most software products, and that problem is that there is too much to them. The code base is too big to manage. There are too many bugs in it. There are too many features to maintain. There are too many features to explain to users. The interface is too cluttered. I could go on. But that’s the gist of the situation.

So how can we realistically set suitable barriers on software products in order to get them to meet the needs of managers, developers, designers, and users? I’ve started to think about this and one possible answer is that there should be caps on everything.

As in, these are your engineering resources, so this is how many hand coded SLOC that you can realistically manage. Keep adding SLOC until you reach your limit.

Or as in, this is the reasonable amount of time that you can expect your users to spend using your software per day. So this is how many features you can include.

Or as in, this is the amount of "stuff" that you can keep up with, so for every new "thing" that you add, you need to remove "something else" or spin it out into a new "thing" with its own resources.

The beautiful thing about jazz lies in the ability to improvise within a given framework. It’s resulted in quite a lot of awesome. Could self imposed constraints of software products do the same?

Background Reading: Size Is The Enemy

Markup, CSS, and JavaScript == Model, View, Controller?

People smarter than me probably moved past that one years ago.

In more exciting news, I'm planning to create a Visual Studio.NET 2005 plug-in that will build on existing work in JavaScript error catching, and enable error catching from within the environment where possible.

Same old tools, sparkly new interface. Hmm... maybe not that exciting after all.

I am terrible at shrill androgyny

Today's tip comes courtesy of a conversation that I had with Dan, the CSS guru at my company. It's a work around for vertically centering a block level HTML element using CSS.

The trick is to wrap the block level element inside of an inline element. That will allow you to use the vertical-align property to center the inline element, and thus the block level element inside of it.

Is it a hack? Yes. But is it an easier technique than some of the alternative methods that I have seen on the Interweb? Also yes.

Necessary Syncopation

Coming back to my smallish apartment in Queens and looking out onto the Manhattan skyline with a nightcap is something that I mega heart. The current in Manhattan can be so intense that it's hard to step out of the flow and think critically about what I'm doing.

I tried a new way of breaking out of that flow today after work, closing my eyes and meditating with the Stone Roses in my ears while riding the train home. It worked far better than I expected it to. By the end of the journey, my mind was svelte.

I am ready for some Michter's, and a throw down with Subversion.