For the past week I have been laser focused on preparing for my presentation at AjaxWorld on rapid prototypting for rich internet applications. I always seem to underestimate the amount of effort it takes to build a really compelling presentation and therefore I always end up making tweaks up until the very last minute. Maybe I'm just never satisfied and believe that it could be just a little bit better. Lucky for me it seemed to work.
The presentation generated an amazing response. About 50 people came up to me during the conference telling me how much they enjoyed the presentation and that I had crystalized their challenges and provided an interesting solution simultaneously. The Appcelerator booth was overwhelmed by people wanting to learn more about our technology. Personally, it's incredibly satisfying when you realize that you've really made a connection with your audience.
Later in the evening I was able to participate in a panel discussion about "The Future of Rich Media and Content Across All Four Screens". At first I had no idea what the concept of "four screens" meant. They are (supposedly) : the theater, the TV, the computer, and the phone/handheld. Each representing their own experience and their own idiosynchrasies. At the end the question was posed "Would your recommend Computer Science as a degree to your child?" Initially I simply answered "no" and tried to leave it at that with no explanation (b/c it was kind of humorous) but when pressed I passionately argued that <rant> computer science curriculums have NOT kept up with the pace of innovation happening in the software world and that our CS students would be MUCH better served learning SQL than learning RS/JK edge-trigged flip-flops.</rant>
Overall, I've really enjoyed the conference so far.
Tuesday, October 21, 2008
Thursday, October 16, 2008
What's next for Quin?
I have been incredibly fortunate during my career and I can say that I have very few regrets. From Tallan (including Carmax, ValueAmerica, & On2) to Interwoven to JBoss/RedHat to Appcelerator it has been an amazing ride. However, today I am pondering my next move. As some of you may have heard Appcelerator has recently decided to close the Atlanta office so I am soon to be unemployed.
I am looking for a senior technical management or evangelism position in the Atlanta area with a maximum of 25% travel. I have a home office now so I can work from home if necessary. I haven't gotten around to revising my resume yet (do people still bother?) but my work history can be found on linked in. If you know of any good opportunities for me please send me an email (matt-at-quinlan-dot-net) or tweet me. If you have already given me a job lead, my sincerest thanks.
Cheers!
-Quin'
I am looking for a senior technical management or evangelism position in the Atlanta area with a maximum of 25% travel. I have a home office now so I can work from home if necessary. I haven't gotten around to revising my resume yet (do people still bother?) but my work history can be found on linked in. If you know of any good opportunities for me please send me an email (matt-at-quinlan-dot-net) or tweet me. If you have already given me a job lead, my sincerest thanks.
Cheers!
-Quin'
Monday, October 13, 2008
Get "Rich" Quick : Rapid Prototyping for Rich Internet Applications
It's the GUI stupid!
Many years ago, I consulted for a large semi-conductor company during the early stages of a software project. They had a highly detailed and fairly rigid process for software projects that started with a complete requirements document based on an extremely verbose and granular template. As the project progressed and I saw the size of the document balloon from 50 pages to more than 200 pages, I had the realization that this document would never be read by ANYONE from beginning to end. The business owners who were responsible for ensuring that the requirements fit their actual business needs were completely overwhelmed by the document's size and complexity. Six months later the business users were given their shiny new software and they were disappointed that the software didn't match their expectations.
In reality, the software was a very solid effort that met all of the requirements specified in the document. However, business users had no ability to read the requirements document and imagine what the user interface might look like for the requirements provided. I remember feeling that the business owners didn't know what they really wanted and feeling resentful of that fact. In retrospect, I realize that almost nobody knows exactly what they want, until they see it. Why? Because to a user, the interface IS the software. Concepts like data models, middleware, rules engines, LDAP, and SSL have no real meaning outside of us techies.
So how do we avoid this? Is Agile Development the answer? Agile is definitely a step in the right direction. It codifies the practices that had evolved in the most successful and most productive software development teams of the 1990s. However, we need more. We need to enable our development teams to prototype the user interface quickly and easily so that users can actually see (better yet, use) the software EARLY in the process. In web 1.0 this was a fairly straightforward effort of building static HTML wireframes. The problem was that this work was largely throwaway b/c they had to be rebuilt as servlets, JSPs, ASPs, PHPs, etc.
As our web applications become more sophisticated this approach starts to break down even further. Today, rich internet applications include syndicated content, widgets, DOM manipulation, Ajax calls, and often a substantial amount of JavaScript. Static wireframes just cannot easily emulate this kind of rich user experience accurately.
What If?
What if you could build the user interface prototype in a matter of days or weeks without a single line of server-side code or even a datamodel? What if the business owner could not only play with this prototype, but also provide context specific feedback seamlessly while exploring the prototype? Finally, what if the prototype wasn't a prototype at all, but was the actual user-interface of the final product (zero throwaway code)... even if you haven't decided which server-side technology you want to use (Java, .Net, Ruby, PHP, Python, Perl)?
This is exactly how we develop software for our consulting customers today using the Appcelerator platform. We've been doing this for over a year now, but we haven't really given it a name until recently. We call it "Interactive Use-Cases". Essentially, we skip the entire functional requirements definition phase and move directly from use-cases to working prototype! This is only possible because of the advantages that the Appcelerator platform provides us. Let me explain.
Technological Enablers
First, Appcelerator's widget library, web expression language, and message-oriented architecture were designed to enable web developers to build UIs with the minimal amount of code (read: JavaScript) possible. As an example, Ajaxian's Dion Almaer posted a small interactive web page on his blog and invited people to port it to their favorite JavaScript framework. Compare the ViewSource of the Appcelerator version to those of the other frameworks. More app + less code = better productivity.
Second, the fact that you are not generating your HTML from server-side scripts frees you from the wasted effort associated with building throwaway static wireframes. Build applications as Ajax enabled .html files which dynamically pull data/content from the server and (re)render those sections of the page accordingly.
Third, our message-oriented architecture is ideal when prototyping because message subscribers in the browser do not care about the source of their messages (that's the point of publish/subscribe architectures). So build the entire user interface with the exact messaging code that they will need for production use. But instead of building a datamodel, DAO objects, DTOs, business logic, and such to provide the actual service implementations, just add a single line to your webapp to include a single JavaScript file containing mock implementations of these backend services. In 90% of the cases you can mock that service with a couple lines of JavaScript that generates a JSON message with a mock payload.
My favorite part about this approach is that once you have gotten sign-off from the business owners, you can remove a single line from the application and all of the mock services have now been turned off. And the server-side programmers have a complete contract of every service which needs to be developed along with test data. Even better, they can choose to implement those services in any language they prefer because the UI is just producing/consuming JSON.
Fourth, thanks to a recent enhancement by Andrew Zuercher, we can easily collect user feedback on our user interface prototype by passing an additional URL parameter which highlights the border of any HTML control on mouseOver. By CTRL-clicking on any highlighted element a feedback dialog box appears that includes the specific page and HTML control being commented on. Users can see other users comments so that feedback effort isn't duplicated. UI elements that already have comments are indicated with red borders.
Everyone knows that prototyping is a valuable exercise that improves the likelihood that the business users will be satisfied with the end-product. However, the limitations of web technology have made it prohibitively expensive and time consuming for all but the most critical web projects...... until now.
Many years ago, I consulted for a large semi-conductor company during the early stages of a software project. They had a highly detailed and fairly rigid process for software projects that started with a complete requirements document based on an extremely verbose and granular template. As the project progressed and I saw the size of the document balloon from 50 pages to more than 200 pages, I had the realization that this document would never be read by ANYONE from beginning to end. The business owners who were responsible for ensuring that the requirements fit their actual business needs were completely overwhelmed by the document's size and complexity. Six months later the business users were given their shiny new software and they were disappointed that the software didn't match their expectations.
In reality, the software was a very solid effort that met all of the requirements specified in the document. However, business users had no ability to read the requirements document and imagine what the user interface might look like for the requirements provided. I remember feeling that the business owners didn't know what they really wanted and feeling resentful of that fact. In retrospect, I realize that almost nobody knows exactly what they want, until they see it. Why? Because to a user, the interface IS the software. Concepts like data models, middleware, rules engines, LDAP, and SSL have no real meaning outside of us techies.
So how do we avoid this? Is Agile Development the answer? Agile is definitely a step in the right direction. It codifies the practices that had evolved in the most successful and most productive software development teams of the 1990s. However, we need more. We need to enable our development teams to prototype the user interface quickly and easily so that users can actually see (better yet, use) the software EARLY in the process. In web 1.0 this was a fairly straightforward effort of building static HTML wireframes. The problem was that this work was largely throwaway b/c they had to be rebuilt as servlets, JSPs, ASPs, PHPs, etc.
As our web applications become more sophisticated this approach starts to break down even further. Today, rich internet applications include syndicated content, widgets, DOM manipulation, Ajax calls, and often a substantial amount of JavaScript. Static wireframes just cannot easily emulate this kind of rich user experience accurately.
What If?
What if you could build the user interface prototype in a matter of days or weeks without a single line of server-side code or even a datamodel? What if the business owner could not only play with this prototype, but also provide context specific feedback seamlessly while exploring the prototype? Finally, what if the prototype wasn't a prototype at all, but was the actual user-interface of the final product (zero throwaway code)... even if you haven't decided which server-side technology you want to use (Java, .Net, Ruby, PHP, Python, Perl)?
This is exactly how we develop software for our consulting customers today using the Appcelerator platform. We've been doing this for over a year now, but we haven't really given it a name until recently. We call it "Interactive Use-Cases". Essentially, we skip the entire functional requirements definition phase and move directly from use-cases to working prototype! This is only possible because of the advantages that the Appcelerator platform provides us. Let me explain.
Technological Enablers
First, Appcelerator's widget library, web expression language, and message-oriented architecture were designed to enable web developers to build UIs with the minimal amount of code (read: JavaScript) possible. As an example, Ajaxian's Dion Almaer posted a small interactive web page on his blog and invited people to port it to their favorite JavaScript framework. Compare the ViewSource of the Appcelerator version to those of the other frameworks. More app + less code = better productivity.
Second, the fact that you are not generating your HTML from server-side scripts frees you from the wasted effort associated with building throwaway static wireframes. Build applications as Ajax enabled .html files which dynamically pull data/content from the server and (re)render those sections of the page accordingly.
Third, our message-oriented architecture is ideal when prototyping because message subscribers in the browser do not care about the source of their messages (that's the point of publish/subscribe architectures). So build the entire user interface with the exact messaging code that they will need for production use. But instead of building a datamodel, DAO objects, DTOs, business logic, and such to provide the actual service implementations, just add a single line to your webapp to include a single JavaScript file containing mock implementations of these backend services. In 90% of the cases you can mock that service with a couple lines of JavaScript that generates a JSON message with a mock payload.
My favorite part about this approach is that once you have gotten sign-off from the business owners, you can remove a single line from the application and all of the mock services have now been turned off. And the server-side programmers have a complete contract of every service which needs to be developed along with test data. Even better, they can choose to implement those services in any language they prefer because the UI is just producing/consuming JSON.
Fourth, thanks to a recent enhancement by Andrew Zuercher, we can easily collect user feedback on our user interface prototype by passing an additional URL parameter which highlights the border of any HTML control on mouseOver. By CTRL-clicking on any highlighted element a feedback dialog box appears that includes the specific page and HTML control being commented on. Users can see other users comments so that feedback effort isn't duplicated. UI elements that already have comments are indicated with red borders.
Everyone knows that prototyping is a valuable exercise that improves the likelihood that the business users will be satisfied with the end-product. However, the limitations of web technology have made it prohibitively expensive and time consuming for all but the most critical web projects...... until now.
The Effects of Open-Source on Recruiting
This is the first of a series of blogposts in which I will explore the impact of an open-source business model on different aspects of a software company. During my tenure at both JBoss and Red Hat and now at my current employer Appcelerator, I have witnessed these sometimes subtle, often dramatic, effects from finance to sales to engineering to IT to support to marketing to legal to human resources. Everyone is affected in an open-source company.
I have always enjoyed technical recruiting. Probably a result of my first employer (Tallan) emphasizing the importance of everyone participating in the recruiting process. The company actually tracked statistics on which employees had passed/failed interviewees and the success/failure of those interviewees who were actually hired. There were no direct financial rewards for being the best interviewer, but there were definitely some bragging rights. It was during this time that I realized just how different hardcore technical recruiting is from almost any other position. When companies hire accountants, managers, lawyers, marketers, and salespeople, so much of the decision was based upon a candidate's history, his/her personality, and his/her attitude. However, when a company is trying to fill a highly technical position, the VAST majority of the decision (hopefully) falls on his/her technical accumen. Technical recruiting is different... and for good reason.
One of the most difficult challenges facing companies who need to fill highly technical positions is to accurately assess a candidate's skillset and knowledge. Notice that I distinguish between knowledge and skills. While I do actually understand the bodily mechanics, balance, and coordination necessary to dunk a basketball... I still do not possess the athletic skill to do so. Oftentimes, the HR department won't even attempt to evaluate the technical aptitude of a candidate, just assuming that the candidate's proficiency on any technical skill listed on the resume is likely to be sufficient for the position's requirements. That's not a dig on HR, how on earth would we expect them to evaluate whether a candidate who lists Oracle as a skill is capable of installing Oracle, designing datamodels, or tuning Oracle databases? It takes a rockstar to know one ("...it's just a handful of people in the world who can tell the difference between you and me. But I'm one of them." - from Goodwill Hunting). When companies do actually attempt to assess technical talent it is often conducted haphazardly by someone who would rather be coding than interviewing candidates. Either way, the result is that the quality of technical talent within an organization fluctuates more than the price of crude oil. And because companies loathe the concept of shedding weak talent, mediocrity becomes the accepted standard.
Enter open-source.
The introduction of open-source into a software company's business model adds a new way to evaluate the technical accumen of potential hires. When looking to add new members to the team, no talent pool can compare with the members of that project's open-source community. Rather than conducting a series of interviews to determine the best candidate, you can easily see who the most engaged, most insightful, and most talented community members are based on their comments, their posts, their blogs, and their code contributions. This approach to recruiting results in a ruthlessly efficient "weedout" process allowing a company to easily identify the best possible candidates. Much like the ability of open-source software to prove it's value before a company invests in support, this model requires a job candidate to prove his/her value prior to consideration.
During my tenure at JBoss I specifically remember that the HR department was not allowed to interview or source candidates for positions on the core development team. You first had to be a contributor. And if your contributions showed that you were a rockstar, then we would send you an email and ask if you would like to make your hobby into your job. Few people declined because it gives them a chance to work on something they are personally interested in (which isn't necessarily true for most programmers).
Next week, Appcelerator will have our first official hire directly from our community. Kevin Whinnery (formerly of Lawson Software) will be joining our team as an evangelist. Kevin has been one of our most active members to date and is in the process of writing a book about Appcelerator. This is a perfect example of someone who clearly proved their worth in advance... and we are thrilled to have him coming aboard. Welcome to Appcelerator Kevin! Are you next?
REPOSTED from Appcelerant.com
I have always enjoyed technical recruiting. Probably a result of my first employer (Tallan) emphasizing the importance of everyone participating in the recruiting process. The company actually tracked statistics on which employees had passed/failed interviewees and the success/failure of those interviewees who were actually hired. There were no direct financial rewards for being the best interviewer, but there were definitely some bragging rights. It was during this time that I realized just how different hardcore technical recruiting is from almost any other position. When companies hire accountants, managers, lawyers, marketers, and salespeople, so much of the decision was based upon a candidate's history, his/her personality, and his/her attitude. However, when a company is trying to fill a highly technical position, the VAST majority of the decision (hopefully) falls on his/her technical accumen. Technical recruiting is different... and for good reason.
One of the most difficult challenges facing companies who need to fill highly technical positions is to accurately assess a candidate's skillset and knowledge. Notice that I distinguish between knowledge and skills. While I do actually understand the bodily mechanics, balance, and coordination necessary to dunk a basketball... I still do not possess the athletic skill to do so. Oftentimes, the HR department won't even attempt to evaluate the technical aptitude of a candidate, just assuming that the candidate's proficiency on any technical skill listed on the resume is likely to be sufficient for the position's requirements. That's not a dig on HR, how on earth would we expect them to evaluate whether a candidate who lists Oracle as a skill is capable of installing Oracle, designing datamodels, or tuning Oracle databases? It takes a rockstar to know one ("...it's just a handful of people in the world who can tell the difference between you and me. But I'm one of them." - from Goodwill Hunting). When companies do actually attempt to assess technical talent it is often conducted haphazardly by someone who would rather be coding than interviewing candidates. Either way, the result is that the quality of technical talent within an organization fluctuates more than the price of crude oil. And because companies loathe the concept of shedding weak talent, mediocrity becomes the accepted standard.
Enter open-source.
The introduction of open-source into a software company's business model adds a new way to evaluate the technical accumen of potential hires. When looking to add new members to the team, no talent pool can compare with the members of that project's open-source community. Rather than conducting a series of interviews to determine the best candidate, you can easily see who the most engaged, most insightful, and most talented community members are based on their comments, their posts, their blogs, and their code contributions. This approach to recruiting results in a ruthlessly efficient "weedout" process allowing a company to easily identify the best possible candidates. Much like the ability of open-source software to prove it's value before a company invests in support, this model requires a job candidate to prove his/her value prior to consideration.
During my tenure at JBoss I specifically remember that the HR department was not allowed to interview or source candidates for positions on the core development team. You first had to be a contributor. And if your contributions showed that you were a rockstar, then we would send you an email and ask if you would like to make your hobby into your job. Few people declined because it gives them a chance to work on something they are personally interested in (which isn't necessarily true for most programmers).
Next week, Appcelerator will have our first official hire directly from our community. Kevin Whinnery (formerly of Lawson Software) will be joining our team as an evangelist. Kevin has been one of our most active members to date and is in the process of writing a book about Appcelerator. This is a perfect example of someone who clearly proved their worth in advance... and we are thrilled to have him coming aboard. Welcome to Appcelerator Kevin! Are you next?
REPOSTED from Appcelerant.com
Subscribe to:
Posts (Atom)
