"Business" Posts
Posted in Business 
Comments
CBQ
On the rails-business list, someone asked recently about Iteration Based Contracts.
“Iterations” in the software development world are a simple, yet powerful concept for developers and businesses. An Iteration is a pre-defined timeframe, usually 1 or 2 weeks, a pre-defined cost, and a general overview of the functionality and goals of an iteration (see also: Iterative and Incremental Development).
Some examples of Iterative development might have one goal:
- Develop a simple back-end server for an iPhone application that allows user registration, signup, and stores user profile information.
Or may include a package of goals, usually building on a previous iteration:
- Add a simple Software-as-a-Service payment processing system to user registration.
Most businesses looking for development really don’t care about the hourly rates when it really boils down to work (i.e., $20/hr for 5 hours of development for one developer or team == $100/hr for 1 hour of development for another developer or team). They really just want their product or service to work, and they would really like to know how much it will cost and how long it will take.
There is an old adage (backed up by some empirical evidence and real-world proof) that says:
“you can build software 1) on time, 2) on budget, and 3) on scope, but you can only pick two….”
This is not to say that no developer team could never do all three, but it’s actually a lot more manageable (and fun) for businesses and developers to fix “time” and “budget”, and alter the scope in Iteration based development.
You might be thinking that we’re still back in Square 1—i.e. aren’t those pesky developers just packaging up a set of hours and time—how will I know what will get developed in that time and for that cost? But, something very cool happens when you really embrace those constraints.
With an iteration, both parties are agreeing to a fixed amount of money and time, and the developers (and product owners) will develop as much functionality and business value within the Iteration. If development on an Iteration begins, and then the business owners suddenly have a fantastic new idea (which usually happens right after the first demo, once they have working software in their hands), they can simply ask the developers to make it happen. Similarly, if the developers think of a great way to simplify a process, leverage an existing plugin or library, or add (or remove) an additional feature, they can propose it without recourse. Both parties know how it affects the Iteration, and thus, the bottom line. There is no concept of the “change-order” and the rapid-feedback-loop created from iterating makes sure that what is being developed by the developers is exactly what the business owners want.
At Highgroove, we have a Master Services Agreement for Iteration Based Contracts, and without posting all the nitty gritty details, the meat of it revolves around the compensation and deliverables:
Compensation. Highgroove shall be compensated for Services at the rate of:
Development per Iteration (Ruby/Rails/JavaScript/HTML/CSS): $xxx
Deliverables are always outlined as attachments to the agreement, and are usually story-based (see BDD).
Iteration Based Contracts require quite a few more mechanisms to ensure that developers are not just packaging up X number of hours—there has to be agreed upon functionality and time-frames surrounding those deliverables within the Iteration(s).
We’ve found that our best clients are really seeking a proven process, and a team that can execute on that process: being transparent and delivering real business value at every step. Iteration Based Contracts are a great way to structure this relationship.
Posted in Ruby on Rails, Business Comments
CBQ
I’ve been in the New York Times newsroom at 5 pm on a Friday, when a reporter dropped in with brand new test score results from across the New York public school system—suddenly, it was like a machine springing to action. There were graphic designers loading SQL dumps of data, collaborating with developers and reporters, all working with the numbers to culminate and disseminate the information, and create factual reporting. It was truly amazing – even better than the afternoon I spent in the pits at a NASCAR race.
I bring this up not simply because of this fantastic article on nytimes.com about these Renegade Cybergeeks at the Times, but because I have seen what kind of great things happen when you put smart, motivated people together, towards great causes.
Last week, we got the chance to work with these developer/journalists (or perhaps journalist/developers) once again—and I couldn’t help but be simply thrilled to help, in a small way, by providing hands-on consulting and training to their Interactive and Computer Aided Reporting Teams.
We’re delighted to associate with these geeks.
Posted in Scout, PlaceShout, Business Comments
Derek
We recently sat down with Geoffrey Grosenbach for the Ruby on Rails Podcast and talked about Scout, PlaceShout, working as a remote team, and balancing client work with internal projects.
Listen to the Podcast
Posted in Ruby on Rails, Business Comments
Derek
Andre and I recently finished the initial launch of Placeshout’s Facebook application. There are several “getting started” tutorials available on building Facebook applications with Ruby on Rails, but there were quite a few issues we ran into that are beyond a “How To” blog entry.
If you are building your first Facebook application, expect very slow going at the start. I’d take your time estimate and double it. Here’s why:
- It takes some time to grasp Facebook in a multi-developer environment. You need to create separate Facebook applications with different names using different tunneling ports. You’ll also need to create several test accounts. Inevitably, I installed one application when I meant to install another. Getting our version control system setup for our development boxes and production system took some time.
- Understanding how Facebook handles sessions. We ran into several issues – knowing when to require an app install vs. a login, handling an app install redirect inside an iFrame application, etc.
- We ended up using a combination of Rails’ #respond_to and unique Facebook-only actions to handle requests. Many of our pages were quite different in Facebook, and trying to fit format-handling in the existing actions only made things more confusing.
- Testing was a pain. Because we integrated with Placeshout.com, we needed to integrate user accounts. Planning and testing integration steps took quite a bit of time. Facebook and rFacebook have some testing conventions, but that’s like saying that because the speedometer in my Ford Escape goes up to 120 MPH, it can go 120 MPH.
- The rFacebook gem and plugin were our weapons of choice. I don’t have any complaints. We modified several pieces of code to fit our application – including creating a user and installing the application, but that’s not out-of-the-ordinary. The rFacebook team has done a solid job in a short amount of time.
In the end, it felt a lot like traveling to a non-English speaking country – at the start it’s difficult to get basic things accomplished. Once you get in a groove though, you enjoy the scenery and forget that at one time, you didn’t throw up when drinking tap water.
Posted in Business Comments
CBQ
You may have noticed a change of scenery on the Highgroove Studios site, and (for those of you not in feedreaders) this blog.
We’ve taken a good look back at where Highgroove has been, and a bigger look at where we’re going.
Here’s a highlight reel from the new web presence:
- We’ve got Andre Lewis (also known as Rails guru, technology expert, published author, geo-location extraordinaire, Alcatraz-swimmer, nice guy). Andre has joined the Highgroove team as a Partner.
- We’ve got products. Placeshout and Scout (limited client-only) are up and kicking!
- We’ve got vision. We’re still focusing on our sweet spot – solving complex problems with simple solutions. Making web applications easier to use. Making technology easier to understand. Embracing constraints. Leveraging Ruby and the Ruby on Rails framework.
- We’ve got great clients. Fortune 500s, government agencies, educational institutions, DemoGOD winners, Salesforce-award-winners, and very happy companies of all sizes and shapes.
Check out our new site, and let us know what you think at hello@highgroove.com.
Posted in San Francisco, Atlanta, Business | 1 trackback Comments
Derek
Atlanta Technology Executive (and recent friend) Scott Burkett blogged recently on what Atlanta can do to emulate the entrepreneurial environment of Silicon Valley. Having lived in both areas, I’ve had a chance to meet and work with many remarkable entrepreneurs.
I think Scott hit many of the comparisons between Atlanta and Silicon Valley on the head. Atlanta is full of smart engineers, isn’t as forgiving to entrepreneurial failures, and like Silicon Valley, does a great job celebrating entrepreneurial heroes.
However, I don’t think the key to sparking innovation in Atlanta is tied to things like tax exemptions, venture funds, and cheap office space. When a company can start worrying about those things, they are already on their way. Innovation comes much earlier on in the process.
What are the biggest differences I’ve seen between Silicon Valley and Atlanta?
Read more... 
