Category: computer

Categories
computer

iCal Domain Account Errors For New Events

Over the past couple weeks I’ve had issues getting my OSX 10.5 iCal client to continue working properly with our centralized CalDav server. I stopped being able to invite other domain users to my events as well as reserve “locations”, despite all my personal (non-domain) calendars continuing to work properly. I noted these iCal errors in Console.app…
*** -[NSConcreteTextStorage attributesAtIndex:longestEffectiveRange:inRange:]: Range or index out of bounds
CalDAVOperationQueue tried to dequeue operation <CalDAVScanDropBoxQueueableOperation: 0x174eb6a0> but it was not at the front of the queue.
When I tried to delete my domain account within iCal’s preferences, the application hung. When restarted I could no longer bring up the preference dialog and saw this error repeated in Console…
*** -[NSURL initWithString:relativeToURL:]: nil string parameter
Apparently deleting everything in ~/Library/Calendars and starting fresh is one solution. I have years worth of notes and interesting tidbits that I need to keep, however, so simply deleting all my data was not an option. With some educated guesswork, trial and error, I discovered that the following steps seems to make everything work without apparent data loss or corruption..
Quit iCal.
Go to ~/Library/Calendars and backup the entire directory, just in case.
Delete all “Calendar Cache” files as well as any directory ending in “.caldav”
Start iCal. It may give you a progress dialog about “Upgrading Calendars”. I think this means it’s rebuilding the cache file.
Go to “iCal -> Preferences…” and delete/readd your domain account.
Wait for the domain account to resync and you should be go to go.
Hope this helps!

appleOver the past couple weeks I’ve had issues getting my OSX 10.5 iCal client to continue working properly with our centralized CalDav server. I stopped being able to invite other domain users to my events as well as reserve “locations”, despite all my personal (non-domain) calendars continuing to work properly. I noted these iCal errors in Console.app…

*** -[NSConcreteTextStorage attributesAtIndex:longestEffectiveRange:inRange:]: Range or index out of bounds

CalDAVOperationQueue tried to dequeue operation <CalDAVScanDropBoxQueueableOperation: 0x174eb6a0> but it was not at the front of the queue.

When I tried to delete my domain account within iCal’s preferences, the application hung. When restarted, I could no longer bring up the preference dialog and saw this error repeated in Console…

*** -[NSURL initWithString:relativeToURL:]: nil string parameter

Apparently deleting everything in ~/Library/Calendars and starting fresh is the easiest solution. I have years worth of notes and interesting tidbits that I need to keep, however, so simply deleting all my data was not an option. With some educated guesswork, trial and error, I discovered that the following steps seems to make everything work again without apparent data loss or corruption..

  1. Quit iCal.
  2. Go to ~/Library/Calendars and backup the entire directory, just in case.
  3. Delete all “Calendar Cache” files as well as any directory ending in “.caldav”.
  4. Start iCal.
  5. It may give you a progress dialog about “Upgrading Calendars”. I think this means it’s rebuilding the cache file.
  6. Go to “iCal -> Preferences…” and delete/readd your domain account.
  7. Wait for the domain account to resync and you should be go to go.

Hope this helps!

Categories
computer photography

MinoHD 720p Digital Camcorder Review

flip_minohd
While no one wants to see your entire 180-minute reenactment of Hamlet, it’s nevertheless nice to have a camcorder handy once in a while. Usually I’ll bust out a pocket-sized Canon SD750 when I need a couple minutes of motion capture, but the SD750–as well as most other low-end digital cameras–aren’t fabulous at video, and can have issues recording single streams over a couple minutes. I’d love something in the prosumer class, but I simply don’t need video recording enough to justify the cost. And even if I did, I wouldn’t be able to fit it in with my normal photography equipment.

The MinoHD is a 720p, 30fps, all digital video recorder roughly volume equivalent to an iPhone: thicker but narrower. Video is encoded in variable bit rate H.264 with AAC audio. (Perfect for use on a Mac.) 4GB of internal flash memory holds about 60 minutes of video, but the storage is neither removable nor interchangeable. The battery is also internal, and charges from the USB connection automatically. A tiny color LCD screen allows for playback and deletion of recorded videos, and provides no special recording effects such as useless cheesy color filter nonsense typically present on consumer camcorders. Costco retail pricing is $179.

Recording a movie is as simple as turning it on and pressing the big red button. Hit the big red button again to stop. It took me approximately 10 seconds to master the process. (An intelligent dog could be trained to do the same if the buttons were bigger.) Use of the “FlipShare” software is not required to transfer video off the device. Just plug it in to a USB port and move the files off. If you choose to use FlipShare, it provides basic video management and editing capabilities, and appears to be necessary to update the MinoHD’s firmware. I’m using FlipShare for now, but like the option of not using it.

Pros

  • H.264/AAC.
  • 720p.
  • USB connector built in. (No need to carry a cable.)
  • Inexpensive.
  • Rediculously usable.
  • PC/MAC friendly.
  • Solid-state.
  • Light and small.
  • No special software required for day-to-day use.

Cons

  • Less than 1080p.
  • No built-in light.
  • Cannot upgrade flash storage.
  • Battery cannot be changed.

Verdict

Highly recommended for those wanting a cost-effective HD camcorder for light, periodic use.

Categories
business computer

OpenRain's First Commercial Product In Production

I feel like I’ve come to know you quite well over the last few years. It was a rocky relationship at first, what with you not paying attention to me and hanging out with your friends too much and all. But ever since you started taking better care of yourself and dressing up a bit before reading me, we’ve become closer than ever.  You see, you and I — me and you — are sharing an intimate connection right now through the Internet. We’re two bits in a byte. Open and close braces surrounding an “<3”. Venerable electronic soul mates.

And because of my undying love for you, Ms. (Mr.? 🙁 ) random person on the internet, I’m going to share something with you that I’ve never shown anyone publicly before…

My company’s first commercially available product: The Online Business Platform from OpenRain.

OpenRain’s managing superwoman may have had a small stroke when I told her she had to produce and post-produce this video, but I think I made her feel better by offering to take all the credit if it turned out well. I’m disappointed that the stunt scenes and Clive Owen guest appearance didn’t come through, but… recession and all that… or at least that’s what I inferred from her half-paralized drooling. So without further ado, please enjoy this awesome video demo of the Online Business Platform that I did all by myself… or not.

Categories
business computer

Preston's Business Razor: A Stakeholder Perspective On Pair Programming

xplogoPair programming is an activity of eXtreme Programming (XP) wherein two developers work in conjunction–often physically seated next to each other with a single keyboard and mouse–to solve the same development tasks as a single mind. Having developer pairs tackle complex tasks can go a long way towards…

  • Increasing personal productivity.
  • Reducing defects.
  • Minimizing misinterpretation of requirements.
  • Improving designs.
  • (Many other benefits.)

As a developer, pairing make mountains of sense. Most tasks in the development world can be improved in a direct, obvious way.

The business perspective, however, is somewhat different. While any give client or manager will say “yes” if they want to see the above occur, a pragmatic developer presenting pro-pairing arguments must, more importantly, provide evidence that stakeholder–not developer–outcomes improve. Let’s look at a few different stakeholder perspectives individually…

Return on investment.

moneyThe common pro-pair argument of “increasing personal productivity” is, unfortunately, a deceptively irrelevant point when it comes to ROI. Business stakeholders will always want to increase productivity, but only if it improve project value per dollar, ceteris paribus. Individual productivity and overall ROI and not always proportional… but we’ll get back to this in a minute.

To play devil’s advocate, let’s create a extreme, cynical analogy by playing stakeholder to a small project that can be run in one of two ways…

  1. Two expert developers arduously working for 2 man-months to complete a small project for a total business cost of $20K.
  2. One hundred college interns assigned into 20 5-man teams, each trying to create a solution equal to or better than the above team could, estimated at 100 cumulative man-months (50x the development effort, but free because they get college credit) plus one man-month of project management and a half-man-month of additional overhead to simply identify the best developed solution. Total cost: $15K.

Now, this latter case is clearly an extreme fabrication of how real-world projects run, but does highlight a Occam’s Razor-like rule for business types…

If presented with two approaches with equal outcomes and equal risk, chose the cheapest. (Aside: This is not argument for crowdsourcing.)

In the latter case, overall productivity, code quality of a random line, design quality and other factors from a random intern will be horrendous. We’ll probable end of throwing out at least 95% of the code. But here’s the kicker… it doesn’t matter. From a business perspective we don’t care about the 95 interns that can’t tell a hard drive from an iPhone. (It’s a problem for another day, at least.) We do care about the 5 brilliant interns that teamed up, overcame the mediocrity of their peers, created something truly magnificent, and saved the company $5K. Despite bad individual productivity, the overall outcome is positive and at an overall lower cost. If we had to apply Preston’s Business Razor to this scenario, there is a clear winner, and it’s not the “ideal” one.

Why is “two” the ideal number?

kittens_huggingIt’s not… except when it is.

In economics, there are a series of concepts related to production possibilities, allocative efficiency, Paredo efficiency etc. that can be applied to engineering: using a group of individuals to maximize the production of various outcomes with limited resources. Here’s a simple empirical experiment that you can run using a group of 15 people and a good 30 minutes that touches on some of these concepts.

  1. Print out instructions on how to make an origami cube, give them to each person, and make sure everyone can make a box on their own. Instruct everyone to make as many fully-assembled, respectable boxes as possible in 5 minutes. Some will be great at it, others less so, and maybe a few that just can’t do it. Don’t count the crappy-looking cubes. Figure out the average time to build a box across the group. This is our “baseline” number that we’re going to try to beat.
  2. Break the 15 people into 5 groups of 3. Each team of 3 will now produce boxes assembly-line style, requiring each member to master specific parts of the process. Measure the production capabilities of each team in 5 minutes and again find the average time to create a box across the entire group.
  3. Reform everyone into 3 groups of 5. The assembly lines will be longer, requiring everyone to become even more specialized in their responsibilities. Again let the groups run for 5 minutes and compute your output.
  4. Lastly, form the entire group into a single, massive assembly pipeline of 15 people. Time the group and compute your output.

origami_cubeWe now have 4 data points in how to maximize the production of the group, as well as some interesting observations. First, in all likelihood, the best overall production probably came in one of the middle two trials. People were forced to specialize, but not overly so to the point of awkwardness. Second, having 15 people do a task with less than 15 significant steps is really awkward. People specialized to the point of meaninglessness; issues in the pipeline blocked way too many people; the shear overhead of literally moving paper around defeated the point of specialization. Third, each group had its own characteristics. Some may have been so productive that they blew away the baseline quota, while other in similar sized teams simply could not work together due to process issues, personality conflicts etc. Each group probably also adapted within those five minutes to maximize the groups output based on who was faster/slowest, and best/worst at folding. Some groups may have created a “manager” role to correct critical pipeline issues, pitch in a few folds when someone gets behind, or fix the “broken” boxes. When in a massive 15-person pipeline, some may have gotten frustrated and wanted to split back into smaller groups.

Let’s put it into a real-world perspective by taking an arbitrary task from an issue tracking system: “refactor foo to support bar.” This task has it’s own optimal number of concurrent developers that will be unique to the team. For a group of interns, maybe it’s 5.5; for a team of superheros, 1.2; for my team, maybe 2.4. This specific task and specific team has its own distinct production characteristics (even though the task only needs to be done once), and only in very rare cases will the optimal number of people assigned to it be exactly equal to 2.0. The point is this…

Asserting that a “pair” of people is always optimal is just as absurd as asserting groups of 1, 3 or 4 are always optimal.

The number is unique per task, per project, per team, and understood outside of computer science when looked at from a businessy economic perspective. So from a stakeholder viewpoint, use of pair programming is absolutely acceptable (and even preferred) when optimal over other options.

Experienced engineers inherently understand that some tasks require multiple minds to collectively discuss difficult challenges, debug complex code etc., and don’t hesitate to seek additional eyes when it feels right. What we should not do is cling to the notion that “2” is a magic number that should be used without contextual consideration. Maybe it’s 3… or 1… or 7… there is no universal constant that can predict this number, and it’s ok that it varies per task.

So for now, let’s put aside this arbitrary “2”, and instead rely on our experience, higher-level intuition, business strategy, basic metrics and strong understanding of our peers strengths and weaknesses when deciding when to pair.

Preston

Categories
business computer personal

My FonWallet Story: Making It All Public

Update: April 26th, 2009. I’ve had a few brief conversations with Todd over telephone and IM, and have offered to cease pursuing both judgments and remove this post from this website provided a prompt, reasonable payment schedule for the personal judgement against Todd. He has committed to proposing me a payment settlement plan by the end of April, 2009. I am currently awaiting this documentation.

There are several areas of this post in which he has taken issue. Since many people have already read this post I am hesitant to silently change copy, so for readability purposes I have highlighted that original copy in bold, followed it with additional personal commentary in square brackets, and Todd’s verbatim remarks in curly braces.

Update: November 1st, 2010. I recently had a phone conversation with Todd, who stated a payment schedule should be possible in the near future. I’ve yet to receive any follow up of meaningful action.

Update: December 1st, 2010. Very minor typographical corrections.

—-

I’ve avoided writing on this for a year and a half now, but have been pushed to do so by several inquiring minds over the past year and a half not affiliated with the company. Some documentation on this can be found in public record, and some not. I will note the points on which I’m speculating. None of this information is covered by any NDA I am under.

The company under discussion is generally known as “FonWallet”, though the official legal entity has changed numerous times and is fairly tangled in the personal affairs of one of its owners, Todd Coulter. {Todd, April 16th, 2009: “This is totally false, inaccurate and easily proven”} [Preston: April 26th, 2009: When I first became involved in the project, most important assets at the time seemed to have direct ties to Todd, personally, rather than the company: such as bank accounts, server assets, and vendor accounts.  At the time, at least, there were a handful of different entities that all centered around Todd… A few I recall were FonWallet Payment Solutions, Inc., FonWallet Payment Solutions, Ltd., MBXIP, SipCellNet… possibly other I do not remember. I do NOT have detailed knowledge of the activities of those additional entities, nor do I make ANY claims as to how–if at all–they currently relate back to FonWallet. Also note that I still have the original stock certificate log books for FPS, Inc. and FPS, Ltd.] I have neither vindictive nor harmful wishes against anyone affiliated with the company: only to be compensated for my work.

I personally performed a significant amount of work for FonWallet, at the time known as FonWallet Payment Solutions, Inc. and now known as FonWallet Transactions, Inc., largely in the first half of 2007. It is a startup operated largely in Phoenix. {Todd, April 16th, 2009: “This is again totally false, inaccurate and easily proven”} [Preston: April 26th, 2009: I personally know more than a few people of current and former involvement with the project that are local to the Phoenix area. Whether or not Phoenix now represents a majority of the projects efforts, I do not know: simply that there is a significant amount of work being done in Phoenix. With regards to the entity primarily associated with the project, all current documentation I can find–including the FonWallet.com website itself–leads me to believe that “FonWallet Transactions” is now the preferred nomenclature. This could be wrong, but from the perspective of a reasonable outside observer, this definitely seems to be the case.]

Employees/Contractors of the company were initially paid as promised, however, dollars dried up around summer and most of the concurrent staff stopped received compensation. The only reason some of us stayed on as long as we did was due to a personal guarantee made by Todd Coulter to personally cover the staff debts if the company were not able. Soon thereafter I moved on. Others stayed. As far as I know, none of the compensation owed across that period has ever been paid, even though the company has been in operation under a new name. I am aware of at least 2 others people owned money by Todd Coulter, personally.

Mr. Coulter eventually became completely unresponsive to inquiries on the matter, which prompted me to file suit. (AFAIK I’m the only that did so.) Mr. Coulter did not respond to the suit. A motion for judgment was made on 12/12/2007, and ruled upon in my favor shortly thereafter.

Two suits were actually filed, with myself (Preston Lee) as the plaintiff for both. The first names FonWallet Payment Solutions, Inc. as the defendant with a ruling of $71,324.32. The second names Todd Russell Coulter personally as the defendant, with a ruling of $24,044.32. The sum total is $95,368.64. I suspect that the company name change was made, at least in part, to avoid having to pay these debts.  {Todd, April 16th, 2009: “This is totally false, inaccurate and easily proven”} [Preston: April 26th, 2009: This is purely speculation on my part, and to be honest, I hope is completely wrong. I do not have insight as to the specific reasons for the creation of a new entity (FT, Inc.), except for the knowledge that the old one (FPS, Inc.) was out of money, had a ruling against it for $71K., and the stock books were were in the possession of the guy (me) who filled suit. Again, I hope I’m wrong about this, but I haven’t been provided with any reasons to believe otherwise.] To the best of my knowledge, Mr. Coulter was properly served on both accounts but neither notified the other owners of the company nor made attempt to respond to the suit.

Regardless, the latter ruling still stands, and I have tried numerous times over the past several years to settle the matter and collect compensation for the months of work and expenses that I am personally owed. I wish all those affiliated with the company the best of luck, however, this matter is certainly not “closed”. There are some interesting and challenging concepts involved and I wish the staff the best of luck. I write this note as a friendly, public attempt to settle this matter once and for all.

Relevant public legal documents are available from Maricopa County, Arizona. If anyone–specifically Todd Coulter–would like to the discuss the issue with me directly, you can reach me direct via email or my cell.

Categories
business computer

Handling Fuzzy Requirements

I had a great conversation with remi Taylor of OpenRain Software today on how to handle fuzzy requirements when the customer isn’t available. You’ve been there… you get an issue tracking ticket like “Add Foozle Support” only to find no explanation of what this means other than the issue title. The customer/decision maker decided to add this ticket as your number one priority 2 minutes before getting on a space shuttle to Jupiter and is unavailable for clarification clear through next month. The customer says it’s the top priority, though, so you’ve got to do something.

The problem is an unaddressed gap in requirements between concept and action. In the customers mind, the concept may be clear. They may have a mental concept of what a Foozle is, what it means to the business, and how it will interact with the rest of the system. They may even have a GUI mockup laid out in mental Photoshop securely filed into the right hemisphere of their gray matter. As the developer, however, you don’t know any of this, and cannot act until you’ve figured out what the fooz you’re supposed to do.

The temptation in this situation is to pick up the keyboard and start coding according to your best guess of what the customer should have explicitly specified, since it’s not possible to reach him/her and you have to deliver something before they return. So you add a “foozles” table to the database, create some forms, tie it into the search algorithm and write a robust suite of regression tests. You are now the de facto project expert on Foozle and Foozle-related issues, and are pretty freakin’ proud of your work. The milestones completes, Foozle support hits production and it’s all good.

The customer returns from Jupiter delighted to find their feature request ticket resolved as successfully completed. They check out the work, and gaze wide-eyed upon the screen. Squinty eyes and an emoticon-like frowny face ensue, and all hell breaks loose. Sound familiar?

Yes: there has been a clear and obvious failure in process and communication. You–the developer–probably even muttered this when the issue hit your inbox, but let’s just assume that this particular real-world situation meant that the “proper” process wasn’t followed for legitimate reasons and you certainly weren’t about to twiddle your thumbs for two months waiting to meet with the customer upon return. Fail? Yes. The customers fault for hit-and-run management? Probably. But could you have handled the situation better? Yes! Let’s look at what could have happened to make an unfortunate situation a little sunnier…

When you first started thinking about the issue, you made the same mistake as the customer: you jumped from concept to a mental action plan without communicating the assumptions under which you made it. You formed your own mental concept of what a Foozle is, what it means to the business, how it will interact with the rest of the system, and created your own mental mockup. Unfortunately, all your concepts and conclusions ended up being completely different from the customers (since you couldn’t discuss them), and none of these discrepancies were discovered until delivery.

For our purposes, the interesting part about the situation is not that the lack of clear requirements prevented delivery of the “correct” system (according to the customer), but that you did not state your mental assumptions about Foozles  because your instincts told you it was a pointless exercise. The customer was on Jupiter and couldn’t possibly respond on time, so why bother? …right? Quite the contrary!

It is critically important to document assumptions on unclear requirement–especially when the customer is absent–because it places accountability of correct feature development back on the customer. What if your first reaction to the situation was to add a comment to the issue like this?…

I’m going to accept and attempt this issue, but I can’t find any detailed information on what needs to happen and REALLY need some customer time (~1-2 hours) so I know I’m going in the right direction. Not having this information leaves me with a LOT of fuzziness on what the expectation are, so here’s what I’m going to do…

[Explanation of your approach to the problem, explicitly making and stating assumptions as necessary in lieu of clear customer requirements. If you need a definitive answer that you can’t get, explicitly define one as an assumption so the reader knows how you’re getting from high-level concepts to lower-level action.]

If any of this is incorrect, PLEASE ping me IMMEDIATELY. I’m going to start development soon and want to definitively understand the intent of this ticket to avoid wasting time!

Your assumptions could be wrong. Really wrong. They could be so wrong that you’ve wasted 100% of your time because the customer made a typo and meant “Woozle”, not “Foozle”. The key difference is that you’ve been proactive in specifying missing requirements and gave the customer a non-confrontational opportunity to clarify their intention so you can Get It Done Right. Your clear, wrong assumption statements on Foozle concepts should–if the client was fulfilling their obligation–have triggered an immediately phone call from the customer. It didn’t, and that sucks, but given a tricky situation you’ve done pretty much everything you can do to assure the system is correct (short of a high-speed intergalactic chase to flag down the customer), and of that you can be proud.

In the best case, someone familiar with Foolze semantics will chime in to represent the customer until they return. In the worst case, the angry customer call will at least go much better since you can point to your desperate pleas for clarification on specific items, timestamped in a timeline manner before any of the “wrong” work was done.

Categories
business computer

Offering Developers Startup Equity, A Dialog

I have this conversation about once a month, generally by a well-intentioned dreamer new to the software space who doesn’t understand why I can’t accept projects for equity. I may be exaggerating slightly, but it sure feels this way…  🙂

Preston: Hi Bill, nice to meet you. How can we help you develop your online venture?

Bill: I have a unique web startup opportunity worth $4B and am accepting HTML experts to implement it.

Preston: [immediately suspicious of the phrase “HTML expert”] Ok, you have my attention. What’s the business plan?

Bill: It’s essentially a combination of eBay, Facebook…

Preston: [senses where this is going]

Bill: …Slashdot and TheSuperficial.

Preston: It’s a news and auction site for celebrity social networks?

Bill: No no no, it’s more like Google meets MySpace.

Preston: Like.. Orkut?

Bill: Kinda, but simpler.

Preston: [completely confused] Back to the business plan part for a minute. Could you tell me about the nature of the business? Is this an ad-based site?

Bill: No.

Preston: Ahh, ok. Some sort of subscription thing then like Salon or TheOnion?

Bill: No way. Users hate paying for stuff. It’ll affect our bottom line. We’re going to keep it free for everybody. And green. We should probably add a database of sites using ecological products. And videos, of course.

Preston: [now confident of where this is going] Let me restate the question. Where did that $4B figure come from?

Bill: YouTube was bought out for $18B. Google will be all over this after we capture 10% market share.

Preston: [completely ignores the issues with those two sentences] I see. To be completely honest, I should share a couple general thoughts. [brings up telephone script #4 from personal wiki] We haven’t talked about budgets at all, but I assume this is an equity-share idea, and I’m really honored you thought of us. There are a lot of great people out there, and I’m happy and thankful to have stood out. Unfortunately, we’re not accepting equity-based projects at this time for two primary reasons. First–and again all in frank honesty–we have the technical, business and other resources to implement these things on our own without external partners. We have a lot of great ideas, and it makes the most sense for us to pursue them internally. Secondly, it’s our goal to treat employees the way we all want to be treated: with respect, recognition and great benefits. That comes with cash flow requirements we just can’t meet with equity-heavy relationships. I’m going to email you some contact information for other resources you may want to follow up with directly, and I think you’ll find that reputable software engineering shops will share these two sentiments in common as a matter of prudence. We look forward to working with you in the future, however, and we’ll keep in touch periodically to check up on you!

[exchange of pleasantries]

Categories
computer personal

Logical Programming With ruby-prolog Slides

rubyI gave a ~1 hour talk last night to the Phoenix Ruby developers group on how to implement logical programming concepts in Ruby using the ruby-prolog gem recently released by OpenRain. Enjoy!

[Keynote] [PDF] [Slideshare] [Code] [Releases]

Categories
computer

The Truth About Integrating Rails In The Enterprise

Ruby on Rails is a great RAD framework. We use it all the time. But one place Rails loses its magic–while not the fault of the framework itself–is with external integrations to legacy systems.

First of all, soap4r sucks. Everyone I’ve seen try to pick it up has gotten frustrated and angry at how awkward it is to write a SOAP client in Ruby compared to Java and .Net tools, which can do the same thing in a matter of minutes. Since RoR IDEs aren’t exactly 1337 yet, we need to put some serious love here as a community to prevent larger companies with heavy SOA leanings from running away screaming.

For some reason, many people seem to think that pouring t3h Rails int3rn3ts into an infrastructure will suddenly trim 75%+ off all development and maintenance costs, complete with rounded corners and shrink-wrapped buttons. Wrong. Many of the development tasks will take significantly shorter times to develop under timeframe expectations relative to Java and .Net, yes, but you can’t avoid costs associated with migrating legacy data and integrating with retarded external systems such as your ghetto-ass SOAP services. Nor should you avoid design activities such as usability analysis or proper testing practices. 

So if you have a web project that lives in complete isolation and does not have any legacy issues with which to deal, OpenRain can bust out that web project in a heartbeat. But if you have unresolved data management and integration issues, there is no acts_as_silver_bullet plugin which can save you the burden of having to actually think about and address those problems. Rails isn’t the cold bucket of water for your data nightmares.

Categories
computer

Hiring For IT: What We’re Doing Wrong & How To Fix It

HR departments for many technology firms tend to be a bit backwards in the way they evaluate potential hires. Early in the process, an HR member or technical recruiter will typically contribute to the never ending stream of listings posted to the popular online job sites, and funnel the subsequent flood of applicants through a filter before passing on candidates to the geeks. The key issue is that HR cannot realistically be expected to hold all the technical knowledge necessary to appropriately evaluate and filter applicants based on technical criteria. Many resumes are thus evaluated solely off keywords or ridiculous automated online exams that supposedly quantify a candidates abilities based off asinine declarative factoids.

My personal hiring strategy, while admittedly skewed towards finding only top tier entrepreneurial people, follows these steps..

  1. Go to the core of The Right Persons culture. Forget about the “Java” checkbox on Dice.com. Figure out what The Right Person does online, and go there directly. Post a Java job to the local JUG mailing list, or a Ruby job to the Ruby talk group, for example. Only people genuinely into these topics sign up for mailing lists and forums, so by going straight to the cultural center of the ideal candidates interests you’ve already filtered out the dingbats who would apply just for the sake of applying. The Right Person is probably already employeed and thus would not be checking monster.com anyway. Allow HR to apply their own filters after you’ve identified the right culture.
  2. Evaluate their communication skills via email and phone. When was the last time you read an uber-competent technologist who ended every sentence with three exclamation points and a smiley face!!! 🙂 Yeah.. me neither. The subtleties of written language reveal how in touch one is with technical culture. They might have extensive experience with 16 different databases on their resume, but if they can’t explain — in layman’s terms — what a database driver does, I can’t see him/her being able to produce well-documented results or be terribly useful in business meetings. Ar-tic-u-la-tion of one’s thoughts in both written and spoken word is critical to effectiveness.
  3. Talk about technology in general. I do not expect you to know the internals of the JVM to be qualified for a Java developer position. I do expect you to keep current on general technology trends and always have your ears open. I expect you to constantly learn and get your hands dirty, and I expect you’ve done some of it on your own time.
  4. Ask the right questions. “What type of Exception does Socket.close() throw?” would be the wrong question. Phrase your technical inquires such that they are open ended, recognize that He/She Is Not Google, and allow the respondent to give an intelligent response even if they do not know the answer. Example: “How would you describe the lifecycle of a network connection?” The question is specific enough such that a knowledgeable person can immediately give a thorough answer, but not overly so such that it is a miniscule factoid you’d see on Jeopardy. Also ask questions which are subjective or provide incomplete information, such as, “Which Java OR/M technology would you use in a new web application?“. You’re not looking for a “correct” response, but to gauge how’ll they’ll react when prompted with incomplete, unclear or clearly stupid business requests. Just like the real world. Arrogance and stubbornness can often show through with a definitive answer to such questions, whereas a more pragmatic person might say “It depends.” followed by a diatribe on the pros and cons of various options, none of which a singularly “correct”.
  5. Invest the time. Many large companies outsource recruitment because they see it as a secondary distraction to the organizations primary tasks. But the thing is… putting the right people in the right roles is as core to your business as it gets. And for the prices charged by technical recruiters, the $20K+ per head can easily be spent on competent geek personnel dedicated to networking in the correct communities for purposes of recruitment.

But don’t fret: there are companies trying to change the system. For the time being, however, keep this mind next time you hear an interview going on down the hall…

Organization and role-specific cultural requirements come first; HR policy requirements come second.