There was a time when I thought my 15" MacBook Pro monitor was plenty large for any given task. Unfortunately (or fortunately depending upon how you look at it), I've been totally spoiled with my dual monitor setup at the office, and found myself sorely wishing for a similar computing experience at home.

I've been out of the monitor market for a while, but a little Googling made it abundantly clear that the Apple Store is out of their gourd if they think I am going to spend $899 for a 23" Cinema Display when there are so many bargains on the market, many of which are a step-up in terms of tech specs.

My monitor at work is a Dell Ultrasharp. Now, I have had really bad past experiences with Dell hardware. I once had a work laptop that would literally fall to pieces as I picked it up, with the removable drive falling out just from the amount of torsion applied to the case by the act of lifting. That being said, it was after sitting for ten minutes one day waiting for this same Dell laptop to wake from sleep that I decided I was never going to work on a Windows PC again, so I suppose I should be grateful to it for pushing me over to the Mac full time.

However, unlike that laptop, I like my Dell Ultrasharp a lot - it has great build quality and is a solid performer. Unfortunately, looking at the Dell site, Ultrasharps seemed somewhat on the pricey side as they are considered the higher-end option, and I wanted to keep my purchase between $300 - $400. So, after consulting our resident IT guru at Highwinds and talking amongst some peeps, I decided on a 22" Dell SP2208WFP, which has a built in web cam. I was going to order it through work for about 10% off retail, but Dell ended up doing a $70-off special that was more worth my while, so I ordered it last week directly through their site. Dell promised me the item was in stock during purchase, then told me after the fact that it wouldn't ship until October, and promptly delivered it to me three days after I ordered it (arriving September 24th). So, they get 0/10 for the web site experience, but 10/10 for a speedy delivery.

As for the monitor itself, it is super nice. Along with everybody else on the Internet who bought one of these monitors and chose to comment on forums, I immediately discarded the factory settings (which make the monitor look like total ass) and tuned its internal settings, along with Apple's built-in color correction utility which I've personally never had success with before now. Luckily, the planets aligned, and I must say the picture is even better than my Ultrasharp at work. I almost bought a 24" model, but having put the monitor in situ in my home office, I am glad I didn't because the 22" is plenty big; seems bigger at home than at the office for some reason. Along with my PodiumPad, I get dual screens by leaving the laptop open, and find myself happy as a clam.

By far the best moment of owning this monitor came when I realized that it had three inputs: DVI, HDMI, and VGA. Along with my collection of laptops, my office at the house is home to my first Mac, a Quicksilver PowerMac G4 tower. Under the impression that the tower only had an ADC connector (hooked up to the 17" Cinema Display I bought back in the day), I was searching online for an adapter to convert ADC to DVI when I stumbled across some information about PowerMac video cards. I was reminded on this web site that the 2002 Quicksilver models came with dual-head video cards, with one VGA and one ADC connector. Crawling behind my machine for the first time in about four years, sure enough I was met with the VGA output. I happily plugged in the Dell-supplied VGA cable, and there was much rejoicing. I have a wireless Apple Bluetooth keyboard and Mighty Mouse combo, so all I need to do is push the button to switch video inputs and I don't need no stinkin' KVM switch.

One note to potential buyers: to switch video inputs, you have to press a button on the front of the monitor. The first press prompts you with "Auto Detect", which (if you are dumb like me) you will interpret to meaning that it will determine which inputs are active and give you a choice to select the one you want. Not so. It took me a few tries to realize that "Auto Detect" is one of four options, the other three being "DVI", "HDMI", and "VGA".

Other nice features include the glossy monitor coating, solid build quality, USB hub, and built-in web cam with microphone. A total of four downstream USB ports (two on the back, two on the side) and the web cam can all be hooked up to your computer using one USB cable. The web cam has a similar focal range to the one built in to my MacBook Pro, with the only noticeable difference being that the Dell's webcam has slightly softer focus (instantly earning it the nickname "Barbara Walters-Cam"). Both the monitor and web cam worked flawlessly after hook up (without drivers) on both my MacBook Pro and Quicksilver tower, both of which are running the latest versions of Leopard; note that you need to power down the tower and connect the monitor before it is recognized, and you should never unplug an ADC connector from a running computer.

iChat instantly recognized both web cams for video conferencing, and let me choose between one or the other in the Preferences dialog. The only other thing I had to do was go in to the "Audio Midi Setup" application and set the monitor's microphone resolution to 48 Khz before it would start recognizing input.

All in all, I'm really happy with my purchase. I got a beautiful, seemingly better-than-Ultrasharp quality 22" monitor including shipping for just shy of $300. I'd definitely recommend the monitor to anybody who is in the market for something that is decent quality without breaking the bank.

This is one of those little, niggling language things that has absolutely no impact on society, but still really drives me crazy when I see it in emails and on web sites because I am such a douche. One of these days, it will drive me to purchase an AK-47 and tour the country with a green bar report listing all the offenders, delivering swift justice Jay-and-Silent-Bob-style.

insure |inˈ sh oŏr|
verb [ trans. ]
arrange for compensation in the event of damage to or loss of (property), or injury to or the death of (someone), in exchange for regular advance payments to a company or government agency.

ensure |enˈ sh oŏr|
verb [ trans. ]
make certain that (something) shall occur or be the case.

Hmm... if CDN execs are unsure about the viability of P2P for video distribution, maybe they should check out our new Octoshape services.

Is somebody calling you, or did you just decide to subject us all to a tinny cellphone-speaker rendition of the latest crap being aired on MTV?

Ringtones are evil.

While still in the realm of academia, these papers provide some structure and proof to the interesting real-world implementations of seemingly-weird database architectures that have popped up recently in order to meet the demands of high concurrency/availability Internet-based services.

"We conclude that the current RDBMS code lines, while attempting to be a “one size fits all” solution, in fact, excel at nothing. Hence, they are 25 year old legacy code lines that should be retired in favor of a collection of “from scratch” specialized engines. The DBMS vendors (and the research community) should start with a clean sheet of paper and design systems for tomorrow’s requirements, not continue to push code lines and architectures designed for yesterday’s needs."

Amen. I'll be watching this space closely.

I thought this press release did a really good job of pointing out some of our strengths.

It's a press release of course, so apply salt to taste, but I think the following statement really communicates what we are about. It's great to see that the way Highwinds operates is so visible to our customers from the outside, looking in. This is a customer quote from Mark Snyder, COO of VirtuPoint in Los Angeles, CA.

"Highwinds has done a great job of acquiring good talent, and their teams have an obvious passion for what they do - both from a technology perspective and a company-wide commitment to customer service. Our customers' videos stream better, faster and more reliably now, Highwinds has been quick to accommodate our requests, and the next-to-real-time establishing of accounts is unprecedented in the industry."

The "quick to accommodate requests" statement is my favorite, since we really focus on this. Meeting new/customized customer needs is a big part of what we are about. In fact, one of the best parts of my job is interviewing customers for their direct feedback (both good and bad) for StrikeTracker, which is presented to executive management immediately in regular product planning meetings. We take customer input to heart, and work hard to make all of our products better to suit their needs. I especially relish these opportunities for direct customer interaction, since my team gets to determine how (and how soon) the resultant improvements are delivered to our customers to enjoy.

Yes, yes, this is a late post - but I have been on vacation for a week with no computer access, so give me break.

I must say that Google Chrome (read the comic) is the biggest step towards a web-based operating system that I have seen in some time. The browser seems to have inherited many of the features you would expect in an OS, such as process and memory management and multi-threading. It will be really interesting to see where this goes.

Carbon Five wrote an article on "Rewrite or Rescue", speaking to legacy Java apps to which they lent their expertise to save.

However, their comments on the habits formed by a fire-fighting development culture and the steps required to transition an organization out of that toward a focus on quality are spot-on for any development platform.

They summarize their thoughts as such: "All too often, the source of poor software quality is poor process and practices. Unless you fix those problems it is not worth embarking on a new software development effort."

This all jives completely with my experiences with system/component rewrites and organizational culture change for development teams. If you have low quality code coming out of your teams, no amount of rewrite will produce a better quality product. You have to address the problem at the core, which is the developers themselves.

Sometimes you have good coders who are failing because they are working in the wrong environment. This is usually very easy to fix. In my personal experience, and from what I've heard often in conversation with industry peers over the years, the usual suspects are (a) insufficient time constraints for architectural planning and (b) throwing out basic quality controls (such as code reviews, and/or the time necessary for writing automated unit tests). These items are usually sacrificed in the name of speed, but (as has been written about countless times before by people smarter than me) the hour or two spent in architectural brainstorming and the extra 25% dev time to write automated unit tests is recouped as soon as the second dev cycle hits, which is usually right after the code goes to production and you get your first batch of new feature requests.

The rest of the time, you just have "bad" coders. I say "bad" because sometimes you have a good coder who has become jaded or lazy and just needs a kick in the ass; in remaining cases you have people who really are not very detail/quality oriented as part of their personality. I'd say for every five "bad" coders I've come across in my career, only one is salvageable; the rest are clock-punchers that sap the productivity of your good coders who have to spend their valuable time cleaning up the other guy's code (amounting to negative effort). The only solution with the truly bad coders is to fire them and seek better talent. Unfortunately, with the state of the tech industry being what it is, it's always a challenge to find better talent. Pick your poison.

Carbon Five speaks directly to the fire-fighting situation, too: "To be successful in a rescue mission or even a rewrite, you have to turn the firefighting culture into one where developers value quality and work for it daily. They should be excited to make things better and be engaging each other with ideas and practices to get there."

As to how to get there: "Again, this can be a very difficult effort. Sometimes it requires dramatic measures. In our experience this includes:

- Changing a workspace to remove barriers to casual conversation
- Relocating developers to the same physical location
- Hiring new blood and firing those resistant to change
- Pair programming
- Book clubs and study groups"

I generally agree with these statements, but have a few thoughts on specifics. I already spoke to hiring new blood and firing the bad, so here are my thoughts on the other items.

Workspace/Relocating Developers
Workspace is definitely a huge factor in developer productivity. I was recently given the option to relocate my development team to another part of the building where we'd be split two to a room. I declined because our current space is perfect for the size of my team: we can all see each other with a twist of the head, be at each other's desks within one chair-roll, and when a meeting is required I just ask everybody to reach a reasonable stopping point after which we have the meeting in five minutes or less from our desks.

Obviously, this won't scale as the team grows. As we get bigger, I plan to slice the team in to squads (of around four coders or less) that can maintain the same gelling qualities as a small team while accommodating the split-up layout of their environment. Experience has taught me that big dev teams are never productive without masses of process to keep everybody in line, which is wasteful and time-consuming. In contrast, squads can be given goals and responsibility for hitting them, after which you can rely on them working effectively as a unit through professionalism and in-team communication. You also get some benefits of having multiple groups relying on each other for components, since the pressure is on to not be the group that misses the deadline (thus holding up the project) or the group that writes the bit that breaks/is buggy (pointing to skill or attention-to-detail issues on a particular squad).

Pair Programming
The XP-based pair programming has never seemed that great to me personally. I just can't see the business justification for two developers working on the same piece of code the whole time.

However, when you have a gelled team, they pair program automatically at the appropriate junctures, for no longer than the time required to get the benefit. When somebody on my team doesn't know how to do something, or can't decide between several techniques, they vocalize the problem to the room and usually get an answer within a few minutes of discussion. In some cases the topic is sticky enough to require a whiteboarding session, which in itself is essentially an impromptu mini-architectural discussion. We already know from experience that architectural discussions yield better end products.

The key take-away I want to present here is that if the environment is right and the team is gelled, you get the benefits of pair programming automatically without needing to formalize or force the issue.

Book Clubs and Study Groups
I'm a big fan of inter-resource training and company-sponsored developer libraries. However, whether or not a company needs to set aside time in a developer's week for clubs and study groups depends largely on the skill set at hand. This sort of thing is a must when you have a lot of junior level coders, but is of much less value with a seasoned team. Seasoned developers will usually initiate their cross-training fix once or twice a month on their own, or at local user tech groups.

One thing they do at Highwinds that seems kind of cool is a bi-annual in-house conference, where all the remote developers are flown in to the mothership and we share the nitty-gritty behind-the-scenes details of the entire system. I'll get to see my first one of these in two weeks, so I'll let you know how it goes.

Conclusions
In closing, we've been approaching some rewrites with StrikeTracker and our web service tier since I got to Highwinds in April. We have not had time to address some of the larger-impact work yet, but we've had good success by identifying a high-level plan of where we want to go and writing new system components/organizing incremental cleanup in that vein.

We identified a few basic tenants: (a) components are developed as agnostic libraries as much as possible, (b) automated unit tests are mandatory, (c) inter-component contracts must be developed as part of the design process and strictly adhered to during implementation, and (d) a new hub will eventually combine the components in a loosely-coupled way. So far, we've hit three out of the four goals without much effort. I've worked on several projects over my career where we've been able to develop new code with this style of plan and plug it in to the old app framework with minimal effort, so I know it works.

Once again, I can only speak from my experiences, but a full system rewrite rarely proves to be a good idea. It's always better to tackle things incrementally so you can course-correct as you go and start extracting value from the new code being produced. Of course, if you're not going to hold quality in high regard as you go, you might as well just stick with the old code and keep on fightin' those fires!