The Highgroove blog. Sit pit-side with us to learn how we work. Sometimes technical, sometimes business-oriented, but always focused on simple solutions.
You are browsing posts about Business. Check out all posts on our blog.
by andy
There is a new drama in the software development community, and it's about whether you should learn to code or not.
I think the best ideas are somewhere in the middle of all the extreme statements and blog post titles that get upvoted on Hacker News.
I think you should learn to "code," but not because it might make you a "coder".
More after the break.
→ Read More
You've read our blog, had Highgroove do work for you, watched our Tech Talks, attended the Atlanta Ruby User Group which we host, and all around think we're great.
Now, you've decided that what you really want to do is hire one of our developers full time to work for you. Maybe you're a recruiter looking to fill an 'awesome position at a big company in the Atlanta area', or maybe your startup is ready to take the next step and hire an in-house developer.
We get a lot of e-mails and calls from recruiters, and to be honest, most of them are absolutely terrible. Read on for some tips on how to recruit Highgroovers to come work for you instead. Seriously. Please. We're not telling you to not try and recruit our developers, but please stop wasting your time and ours.
→ Read More
It's true. We're hiring. Like a lot of technology companies. But, did you know that we are turning down many qualified applicants? Since we started tracking, only 11% of applicants who go through our hiring process become "Hired Full Time" employees of Highgroove. That means about 1 in 10 who apply receive an offer letter. Why is it we can -- or rather why we have to be so picky in who we hire?
→ Read More
by chris
Read on for why you should be using a combination of Sublime Text 2 and Vim instead of Textmate…
Anyone that knows anyone at Highgroove knows we're not your run of the mill rapidly growing Ruby development shop. We're a unique team of creative individuals bent on productivity hacking and iterating on client needs until the app is awesome. Sure we've got some great perks and compelling reasons to make the commute into the office despite being a ROWE. What do we do at Highgroove as a group to intentionally keep our culture cool/unique as we continue to grow? Read more to learn about we stay keep our groove at Highgroove.
→ Read More
Meetings. Quick chats with our customers, daily if possible, don't count as meetings. They keep everyone on the same page to make sure good progress is being made for them, to address any questions or concerns they may have, and possibly to plan the next steps to take in developing their app. By "meetings" we mean that word that brings dread to the heart of anyone who has ever looked at their schedule and seen only two hours of their daily schedule available for actual work, and in fifteen minute blocks no less.
At Highgroove we have a few tactics for avoiding just that. Firstly, we don't have many. Moreover, all meetings are optional, and you can come and go as you like. A quick glance at my calendar shows vastly more pairings, personal trainer sessions, hack nights, team dinners, and other informal team outings than it does meetings. We consider this a win. Like all companies we still need some variety of status updates, the kind of subject matter that would usually go into a weekly company or organization meeting. To address that need we "bring it in" for the weekly huddle emails.
→ Read More
by jason
Companies often feel that they are getting the most out of their employees if everyone is working as hard as possible for as long as possible. However, this can be exhausting on the employees and can lead to diminishing returns. We feel that the better approach is to emphasize efficiency over effort, and our level of productivity speaks for itself.
→ Read More
by jon
In January of 2012, after spending the holidays 'funemployed' (OK, just on vacation) down in sunny Florida logging some EPIC miles, I very excitedly boarded the Highgroove ROWE-boat as our first Account Director.
The month of January left me dazed but not confused. Working in a ROWE environment means results are expected immediately (and that results are all that matter). I hit the ground running and quickly found that everyone here is equally vested each project's success. That is to say, pardon the pun: "the rising tide lifts all boats" here at Highgroove. By leveraging constant communication, the best tools, pair programming, code audits, and project retrospectives -- we truly are an agile shop.
Read on to find out how I learned about what we do best, what makes us different, and what that means to me as our Account Director.
→ Read More
by andy
At Highgroove, we love giving each other compliments. In fact, since everyone at Highgroove kicks ass in some way, compliments are constantly flying around (actually, I think that in and of itself was a compliment).
Well-deserved compliments foster teamwork, increase morale, and make us better as a team than we could be on our own.
One specific way we compliment one another is by giving the Highgroove Award. The award can be given by anyone to anyone; the recipient is recognized on the website and with a physical trophy (it's a bit over the top on purpose!).
Read on for how we added a technical twist to giving the award.
→ Read More
Far too often there exists a chasm between the client paying for and the developer working on a particular project. One party has a longterm vision; a vision that will ultimately impact his/her financial future. The other party has a much closer view of the project, which creates the risk of getting tunnel visioned. The client worries about when the project will be completed; the developer worries about how the project will be completed. When this happens, communication becomes difficult and frustration builds. How can this be avoided?
→ Read More
by drice
Highgroove Studios has taught me a lot about Software Development, Consulting, and building new web applications. Apart from the myriad of technical skills I've added since I came on board, Highgroove is a fantastic company to learn how to build your own web apps, how to design them, and how to remain focused on the most business critical aspects of the system. Highgroove taught me these things by adhering to a process which manages Agile development, responds to changing software requirements and business needs, and encourages constant communication. While these are all noticed by clients, there is one part of the Highgroove process that goes largely unseen; however, it is just as integral as the former three. That behind-the-scenes aspect of the Highgroove development process is keeping the software as simple as possible to meet current demands.
→ Read More
by mike
At Highgroove, we like using the right tool for the job, but we also don't like getting too bogged down in thinking about what we should use. We recently switched our internal company chat from Skype to Campfire, but it wasn't a just simple switch to flip.
→ Read More
by cbq
Today, I attended a workshop from the Atlanta EO chapter led by the charismatic Jim Ryerson of Sales Octane on improving your sales process, through the use of a Sales Playbook. I'll admit, I've always been pretty good at selling (it helps to have an awesome team and product behind you), but the Sales Playbook we have (and that went through a ton of editing today) makes it even easier.
What's in a Sales Playbook? Ours contains things like:
→ Read More
by brandon
As an index investor, I was fascinated when Y Combinator launched their innovative style of startup investing.
Y Combinator spreads their portfolio over a large number of startups, similar to the way an index fund spreads its portfolio over a large number of holdings.
Furthermore, with smaller funding amounts at risk, Y Combinator can provide guidance with a light touch from afar without micro-managing. Similarly, index investors do not concern themselves with the minute details of the companies held in an index fund.
At Highgroove, → Read More
by cbq
We’ve got an amazing team of personable, optimistic, trusting, true-craftsmen developers (and a whip-smart office manager) at Highgroove.
We’d love to keep everyone on the team happy, productive, and with us for a long, long time. However, we realize that even our team of A-players may become ready to move on to different opportunities. We have alumni from Highgroove at some of the coolest companies in the world: Scout, Twitter, Github, and Scoutmob to name a few.
When it’s time for a Highgroover to move on, we have an awesome Exit Interview we give.
by vanstee
What do new hires at a software development shop typically do on the first day? They probably read through documentation, checkout some code, and maybe make some commits on a project. At some of the more progressive companies, new employees might even get to push changes to a live production server. At Highgroove, in my first week, I learned that we follow the philosophy of “Bias Towards Action” and actually “Deploy Code on the First Day.” It’s simply the best way to bring people up to speed and make sure they are comfortable deploying and delivering working software.
by brandon
At Highgroove, we value customer service along with programming. Our customers arrive at our shop with concerns needing attention. Here are a few common ones:
It helps us to imagine questions our customer might have:
At Highgroove, we’ve been consulting on software projects since 2006. I can tell you that it’s been a long, hard learning process on how to sell service based consulting. We’ve certainly come a long way in helping our clients be happy about the services we provide.
by cbq
On a recent project, we’ve been keeping track of the lines of code, and it’s continually going down. You may be thinking — how is the project progressing? With less code, is the application doing less or providing less functionality?
Quite the opposite, actually.
I, along with Charles Brian Quinn, recently attended
A Day in the Life of Agile: Hands-On Workshop presented by Pillar Technology Group.
At this one-day, intensive workshop, we had fun learning and demonstrating agile techniques while attempting to replicate the video game Space Invaders! The training reinforced agile concepts we use daily here at Highgroove, provided deeper insight into agile techniques which we could improve on, and emphasized aspects to agile development that Highgroove will definitely be embracing in the future. As a manager and client liaison, I was especially interested in the concept of Value Centered Design. Value Centered Design supports client needs at the highest level, encourages focused development, and fundamentally promotes efficiency. Here are my notes"¦
It’s amazing to look back at Highgroove’s Top 10 Moments of 2006 while compiling this list of our top 10 moments of 2010.
While this list isn’t as good as the Top 10 Videos of 2010 or the Top 10 Fails of 2010, we sure had fun this year with our amazing clients.
We’re looking forward to a great 2011 — now where is our jetpack and the flying cars we were promised?
by cbq
At Highgroove, we’re not Designers. We’re back-end Ruby on Rails experts. However, we love working with Designers of all types: UX/UI Experts, Wireframing Experts, PSD to HTML gurus, and other hyper-specialists, as well.
We love crisp, user-friendly interfaces that are simple, and straight to the point. When building a web application, it’s tempting to try to design out all the screens or flows that a user (or visitor) to the web application will see, but it’s practically impossible.
What inevitably happens when doing BDUF (Big Design Up Front), is that we all assume “that designers are able to foresee problem areas without extensive prototyping and at least some investment into implementation.”
For some web applications, “slapping on design at the last moment” can work (especially for internal-only, quick and dirty prototypes), but the best way to design a web application is Iteratively, on-going, while the application comes together (during implementation).
We’ve created a couple of documents and how-tos, internally, here at Highgroove to get smart designers up to speed on how to use version control systems like git (using the GUI interface, versus the command line), and how to design a web application that has ways to handle empty screens, error messages, etc. By getting Designers up to speed quickly and using light-weight tools, it helps us version HTML/graphic changes, and respond iteratively to both client requests (“can we make this smaller?”) and functionality requests (“can we simply add a ‘login as this user button’?”) to web applications.
Besides finding the perfect designer who is also the perfect developer (and also the perfect project manager and communicator and content writer and tester), what do you do to iterate on Design when building web applications?
At Highgroove we do Iterative development. There’s no better way to create software, than incrementally, with planned releases every week (or every 2 weeks). Here are some tips that we’ve learned that make Iterative development work:
What other tips do you use to make Iterations successful?
by megan
I’m not a technical gal. I can navigate my way through any application, but don’t ask me how it works. As a manager I am often frustrated by the limitations in our management software. For the most part I grumble my way past the inefficient idiosyncrasies and find little cheats to cut 5 seconds off my process here, 10 seconds there. Fortunately for me my desk is rather close to that of our president and development guru Charles Quinn. When he tires of my grunts, mumbles, and groans he inevitably turns to offer assistance. To my surprise he often responds to my frustrations in agreement, “Yes, that feature should be available. That is a great idea. You should request that feature be added.”
The idea that I could request a change in functionality to an application had never entered my mind. I am accustomed to using either stagnant software made by big names and mass marketed to a general audience or industry specific applications that are, cough cough, built using Access and marketed toward a very specific audience. In both scenarios the product tends to come as is or in edition format. If you want to see a change in the product, you have to wait for an undefined period of time until the software company releases the next edition.
I started sending feature requests to the incredibly responsive support team at letsfreckle.com. We use letsfreckle.com for time tracking and internal management. To my surprise, my requests materialized almost immediately! Within a few weeks I was using all of the features I had requested. Though these features may seem small, they have reduced the time I spend generating reports by 50%. My grunts and groans are now replaced with cheers and excited sighs of relief.
Highgroove loves rails and loves agility. Agile is defined as being active. Active is defined as being in a state of progress. We use rails apps wherever possible which I assumed was our way of supporting the community. Now I know that we use rails apps because they are built by agile developers and are therefore adaptable to our needs. Sure, we tend to support our rails community, but we choose products based on functionality and agility.
Does your software adapt to your needs? What agile software are you using?
by chris
nephophobia. Part of Speech: n. Definition: a fear of clouds. Etymology: Greek nephos ‘cloud’. – dictionary.com
If you haven’t been completely overwhelmed with the hype surrounding Cloud Computing,
chances are pretty good you are living under a rock (and not reading this blog!). Here at Highgroove, we’ve avid
users of the cloud because it lets us spend our time building kick-ass Ruby on Rails apps instead of replacing hard drives in servers.
That said, there is something pretty suspicious about the cloud. I’ve always owned servers at a colo as it is reassuring that I can go kick/hug them as needed. If something breaks and drops off the network, my datacenter is a short bike ride from my house and I can be on a
console in a few minutes. All that Amazon will tell you about their cloud is that they have a few datacenters
in a few different places, and that your virtual servers could drop out of existence at any time without warning!
Working at Highgroove, my fear of the cloud has somewhat dissipated. Chef lets us quickly and easily
spin up servers in the cloud. Seriously, it’s a one liner:
knife ec2 server create "role[super_sweet_app_server]"
The vast majority of our customers are in the cloud on Amazon EC2, Rackspace Cloud Servers, Engine Yard App
Cloud, Rails Machine, etc, and most of the time everything Just Works. It’s easy to add capacity to heavily
loaded applications, and this approach lets us do agile things that wouldn’t be possible without the cloud like refactoring production architectures.
This is pretty nice! Until it isn’t…
I needed a couple of Amazon EC2 instances last week for a project in a particular availability zone, and it was out. That fancy one-liner knife
command refused to run, and no additional capacity was available there for getting done what I needed to do. I had to push back that project, work on
something else, and it took over 24 hours for capacity to become available again. Faster and cheaper than buying new physical servers, but it’s pretty
frustrating when you’re used to instant gratification.
Also, with Amazon and some other providers, there is no guarantee that your virtual server won’t just disappear. This is a blessing in disguise
because it forces you to architect applications in ways that tolerate failure, but for small customers that only need one lightly loaded cloud server,
the cost-benefit equation doesn’t always allow it.
My Nephophobia is mostly in remission, but I’m not selling my rack of servers any time soon.
by cbq
InfoEther has finally released their Ruby and Rails Ecosystem White Paper to the public. It’s a thorough look at the Ruby and Rails community, the individuals, vendors, services, and shops that all comprise this wonderful ecosystem.
We’re happy to report that Highgroove Studios is one of the vendors identified that contributes back to the community in the form of our work on Ruby, Ruby on Rails, Training, Speaking, and the various plugins and libraries we maintain. Also, Scout makes a cameo (it should be on the tools page, too)!
by jonathan
As relatively new parent, my oldest is about to turn five. I’ve attended enough young kids’ birthday parties to develop a standard rating system for a
successful party. My rubric is simple and effective.
Its a simple system and it has helped me plan my own kids parties.
Good projects work the same way. A simple set of guidelines, when followed, insure success. Of all project guidelines, effectively managing scope is the most important. Pivotal tracker, our agile project management software of choice, keeps us on the straight and narrow when it comes to delivering value to our clients. This point was driven home for our recent work on a client’s project.
I just got back from Matchstic’s May BrandCamp — a 2-day intensive workshop for companies on branding, and specifically for helping companies define their own brands.
I am so excited about what we learned about Highgroove, and what makes our team so unique and special, when compared to all the other software development shops. It used to be our differentiator was Ruby and Rails, but with so many other companies now realizing the competitive advantage (or at least claiming they know it), we’ve come to realize that our clients love us for many many other reasons. The fact that we’re experts in Ruby and Ruby on Rails is only one of many factors.
I’ll be blogging more about what we’re doing to help solidify our brand — the brand we already knew and had, but now has become so much more clear.
by cbq
One of our client’s web services (an API) experienced some brief downtime recently, related to an error on our part in rolling out some new data.
Things like this happen — they’re inevitable when dealing with even simple APIs and web applications. But, it’s not the downtime itself that is the main problem, it’s the communication of the issue, the solution, and the future prevention that are more important.
A first draft of our e-mail to the client had a sentence like this:
“Our sincerest apologies for this service hiccup, we always strive for the highest quality products and services and feel terribly when something like this occurs.”
This was quickly scrapped, since this sentence:
Instead, we just simply outlined 3 main points:
Much better, don’t you think?
Most developers think that every “other” developer’s code is “no good.” In fact, it is exactly this “Not Invented Here” syndrome that makes it dangerous for other developers to evaluate an existing project’s quality without a checklist or template as a guide.
Here are a few of the things in Highgroove’s Code Review tool-belt, that we look for:
Even when we come across a project that may not contain many of these quality indicators, it’s not the end of the world. Once we’ve identified the broken windows, we can get to work fixing them.
Photo Credits:
by 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:
Or may include a package of goals, usually building on a previous iteration:
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): $xxxDeliverables 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.
ProPublica is an independent, non-profit newsroom that produces investigative journalism in the public interest.
Yesterday, NPR’s Marketplace aired a segment featuring their “Eye on the Bailout” — a Ruby on Rails application to track the $1.1 trillion taxpayer-funded bailout. Behind this Rails app is a one smart development and investigative team. The app is fully RESTful (allowing developers to pull and syndicate bailout related data in several formats), and it also pulls in feeds from several different news sources.
Highgroove was all too eager to help, but the real credit goes out to the amazing development team, led by Dan Nguyen and Scott Klein.
Read the segment on Marketplace.
Link: Eye on the Bailout
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.
We’ve made a few slight changes to the Highgroove Studios site. Here’s the lowdown:
An emphasis on experience. We’ve been building Ruby on Rails applications since the framework existed. Along the way, we’ve published books, and contributed to a few, too. In short, we’re extremely proud of our time with Rails and want the world to know about it.
Updates to the Highgroove Team. We have some real experts on our team. From Ruby core developers, to former Big-5 Consultants — we’ve been around the block and we’re very proud of our accomplishments. Be sure to check out the updates bios and the new members.
A showcase of our work. We have been involved in a lot of successful projects. We’ve been in the trenches at lots of companies, working with lots of smart people, and it shows.
In true Highgroove fashion, we’ve launched it already, so we can tweak it as we go.
by derek
You need to be in the Bay Area. You shouldn’t be in the Bay Area.
You need to work crazy hours. You shouldn’t work more than 4 days a week.
You need to raise as much money as you can. You shouldn’t raise money.
The topics above never seem to get old and I think it’s unfortunate.
Just run your business the way that feels right. The majority of your time during the week is spent working. Whether you’re working for yourself or for someone else, if you’re not working the way you want to, it won’t last.
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.
by 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:
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.
by 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:
Check out our new site, and let us know what you think at hello@highgroove.com.
by derek
There’s a very easy way to ensure that your project won’t be quoted by a quality, not-starving-for-work web development firm: make the firm sign a Non-Disclosure Agreement (NDA) before you provide an overview of the project.
We care about confidentially and security, but we don’t sign an NDA until we hear an overview of the work. There’s too great of a chance that something you want done is currently living in one of our current projects. We don’t want to get involved in a legal gray area.
So now for the real reason.
In my life, I’ve never overhead an original, compelling idea that I could act upon better than the person who thought it up (this doesn’t discount the idea that I’m just not as smart as everyone else…but that’s another blog post).
If Mark Twain gave me an outline of The Adventures of Huckleberry Finn and said “there’s everything – go ahead and write it!”, the book would have been better suited for kindling than English class. I don’t have the skills to put together a great novel (let’s be honest – I don’t have the skills to write a poor novel).
Smart people know this. It’s not the idea – it’s execution, domain knowledge, and leadership.
by 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?
