For those of you riding the social media train, let’s connect!
Personal
Professional
This morning I had the pleasure of doing a guest spot on Career Launch with Jane & Al: a VoiceAmerica Variety show airing live every Monday from 8-9am. Today’s discussion was on the role of social networking tools in the employment process.
Lots of capable people are finding themselves particularly hard pressed to find jobs right now, being in the midst of a recession and all, so if you’re interested in learning how social networking tools (LinkedIn specifically) can be incredibly beneficial for your career, check it out!
[Stream on the web.] [iTunes podcast.] [Direct MP3 download.]
Full disclosure: Jane & Al–the hosts of the show–are clients and friends. OpenRain developed the Compass Consulting Team website.
On Monday, July 13th at 8am I’ll be doing a guest spot on the “Career Launch with Jane and Al” internet radio show. I’ll be present to discuss the role of social networking and social media tools in the career advancement process: specifically LinkedIn and Twitter. Compass Consulting Team (run by Jane and Al) is an OpenRain client, and they are insanely positive and fun people with which to converse. I’m highly looking forward to it!
Show some love and try to catch the show live!
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.
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.
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]
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.
OpenRain’s heater when out recently, and it got cold. Property management figured out how to hack the unit into a working state again, but only after some badgering. Ben dropped some not-so-subtle hints 🙂
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.