Preston: Hi Bill, nice to meet you. How can OpenRain 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 development shops out there, and I’m happy and thankful we stood out to you. 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]

After a long confusing Ruby debate today at OpenRain on the merits of functional, Erlang-esque write-once-read-many variables, I’m going to step onto the podium and just say it… Ruby should get “final” or “const” variables in a similar semantic style to Java, except at runtime. Rather than ramble on for 12 paragraphs explaining exactly how this might work, read this fictitious Ruby code snippet instead. (Optional: Also check out the chapter on “final” in Hardcore Java.)

Final variables like this are really just an inline TDD mechanism.

Allowing local stack data to be constant provides no functional enhancements to the software, but alleviates the need for certain types of tests by using the compiler and/or runtime to assert certain memory is immutable. The “friend_best” method variant in the code snippet would obviously break most existing Ruby programs, but ups the bar for defensive programming by preventing many common bugs out-of-the-box while still providing support for traditional Ruby variables. At the very least we should have something like “friend_better”. Adding this information to the parse tree will also make it easier for IDEs to provide features more easily implemented for static languages.

TDD/BDD is in–no qualms about it–but we can make our code safer, cleaner and more concise by applying some of the lessons learned by our statically-typed language cousins over the last few decades.

Publishers are also rejoicing, as many have been effectively sitting on completed books in anticipation of today. iPhone SDK Development by The Pragmatic Programmers is already available for immediate electronic download, and an O’Reilly representative has informed me that O’Reilly Media has just released iPhone Forensics.

It begins.

While we don’t regularly use titles at OpenRain, we nevertheless have to distinguish senior talent. The core issue is, “How to you objectively identify ‘senior’ engineering qualities?” Today we’ll focus on several key factors always present in quality engineers, independant of language and platform.

Instinct

He/She has developed extraordinary technical relevance filtering to the point of being able to scroll through a never-before-seen 500 line file in a language they don’t know, and tell you..

• how complicated the code is.
• where potential bugs are.

Even with no formal knowledge of code smells or design patterns, a senior developer can sense ugly code and architecture from a mile away even if they don’t yet know exactly why.

Foresight

Long-term implications are always on the mind of the Senior Software Engineer. They’ve been through the end-to-end development process (from requirements gathering to product maintenance and end-of-life) numerous times, know what issues are going to arise and will point out a suitable solution long before the symptoms start to appear. (This quality thus becomes most apparent after delivery when work is bombarded with never-before-seen use cases.) The truly elite developer is often hard to identify because they’re solving the important issues before anyone else notices the problem. (Ben is a primary example of this extraordinary perceptiveness.)

Results Focus

Knowledge without application leads to arrogance without insight. Senior developers are always focused on results which stand the test of time and can easily see through posers who fluff their way through status meetings.

Communication

New developers seldom understand the required differences of communication between different types of stakeholders. Newbies tend to treat all stakeholders as authoritative figures, and are quick to lose direction when exposed to people with differing incentives.  The criticality of non-verbal developer communication is also apparent to the senior engineer.  For example, a green engineer may see issue tracking as micro-management, automated testing as an ideological obsession, and project planning as administrative overhead, but these are all monumentally important aspects required to keep all developers and stakeholders in a real-time communications loop, since many do not directly interact. A senior engineer will see these concepts as empowering and often get grouchy when not present because NOT having clear priorities and documentation introduces roadblocks to results.

Time & Priority Management

A senior engineer can more-or-less tell you what their schedule looks like a week out, even if it’s not written down, and won’t be hesitant to express any issues with workload ahead of time.

Estimation

New software engineers seem to invariably produce time estimates magnitudes off from reasonable numbers. The issue largely appears to be one of Foresight since accurate estimates are oft best produced by benchmarking current requirements against past similar project experiences: a task more easily accomplished with experience. This issue is an arguing point against the “Customer is Always Available” aspect of eXtreme Programming since a green developer is generally more likely to over-commit a workload than a senior.

After a few grumpy emails between myself and our Account Manager, I’m happy to report that we have purchased the GA release and it’s working well. If you are using Parallels Server for internal development purposes and not for hosting, they will extend a more reasonable price per machine: $200 + $50/year maintenance. I think that’s a very reasonable price point for our usage, and am happy to pay it.

This likely has more to do with meeting end-of-Q2 sales quotas than attracting my dinky business, but regardless, a win is a win! Thanks!

The above image has not been doctored. It’s my normal OS X desktop with Windows XP running in coherence mode. When activated, the window around the XP virtualization session vanishes, the XP taskbar integrates into your OS X desktop, and XP application windows are free to float around. With Parallels Tools installed each XP application has a dock item which can be Command-Tabbed to. If you look closely you can see I’m running IE 6 next to Safari, both natively, without the visual distraction of the virtualization window. This is a huge usability landmark. Thank you Parallels!

Try it yourself by selecting the View -> Coherence menu option when running Parallels Desktop.

(Question: Does VMWare currently have a feature like this?)