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 Iterative Development. Check out all posts on our blog.
by drice
I've been developing Rails applications since version 1.2. Having worked through several major Rails upgrades, I've learned the true value of writing tests. Simply put, tests provide confidence that features will work as designed, and will continue to work in the future. Read on and I'll delve into my own process of deciding what to test.
→ Read More
by jon
At Highgroove, we're no surgeons, but the folks at Hope Builds are. Though we aren't trained to use scalpels, we're really good at writing Rails applications, and that's just what they needed to make their surgical work more effective.
→ Read More
by aubrey
At Highgroove, we aim to be fast. When we jump on a project, we work with the client to understand their goals and begin delivering functionality on the first day. As the project progresses, we strive to increase the velocity of work on the project with each passing iteration.
Our ability to deliver high-quality work at an ever-increasing rate depends heavily on our process—specifically, the three things we do on every project.
→ Read More
For those following along at home, you know that we love to work iteratively, and as such, work towards our big-picture goals one small step at a time. We also take software quality seriously, and an important part of software quality, particularly when it comes to web applictations, is security. We've begun to develop a new process to address security in our applications. In the process we also want to contribute back to the community where we can because it will make the entire web ecosystem that much better. After the break we'll talk about our high-level process and how we implement it.
→ Read More
by aubrey
Prior to working at Highgroove, I worked for a number of softare product companies. One of the best metrics I've found for measuring how great a company is to work for as a developer is the Joel Test, which is a list of 12 simple questions. I've worked at companies that have scored high and companies that have scored low, and please believe me when I can tell you that the issues on that list really do make a difference.
My only issue with the Joel Test is that it is really geared toward software product companies. While a lot of the ideals translate to a software consulting company, the specific questions don't always apply when you are working on a lot of projects for a number of clients. So, in an effort the help measure what makes great software consulting teams so great I present...
→ Read More
by chris
Refactoring is a something we spend a bit of time on at Highgroove, so much that David recently wrote about refactoring and related tools in Red, Green, Refactor and I'm writing with even more on refactoring and the 'Refactoring Rabbithole'.
"When refactoring, it's easy to see 10 other things that probably should/could be refactored"
Spending time on refactoring is a tough sell to clients: by definition, the 'backend' can be completely re-done without any visible changes in an application. As the complexity and size of a project grows, refactoring can be necessary to keep things as simple as possible, keep the code quality high, and keep the number of bugs low.
→ Read More
It's easy to say "We're agile" and "We use Behavior/Test Driven Development" and thus "we use the right tools to empower our developers!" but what are those tools? For me that discussion is entirely about the tool stack you choose, how that stack empowers you as a developer to do things right the first time. Luckily thanks to the ruby community as a whole we have a large number of high-quality choice to choose between.
→ 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 pamela
At Highgroove, we like forward momentum. This means that we know that every delivery cannot be perfect, so instead of worrying about perfection, we worry about progress.
→ Read More
by andy
I have only been a professional software developer for a few years, but I feel like I have already acquired bad habits.
One of the hardest for me to break is the desire to create software in a cloistered environment where the requirements are stable and the best technical approach always wins over other constraints like schedule and cost.
Thankfully Highgroove's iterative software development process forces me to flee from these broken methods of building applications.
Read on for more of my thoughts.
→ Read More
by brian
Highgroove's "bias towards action" rallying cry is no secret, and we try to abide by that rule whenever we can, whether we're deploying or choosing where to go for lunch. An important corollary is that we try to bias towards making mistakes earlier rather than later, too. A fellow Highgroover captured it well by saying: "If you aren't getting burned, you need to play with fire more."
→ Read MoreJeff and Tim at The Pragmatic Bookshelf wrote a great blog post on "The Only Agile Tools You'll Ever Need" which reminded us that it's been a while since we talked about tools here.
At Highgroove, we love our tools. We blogged about 'Trusting Your Tools' almost a year ago, and then about some of the other tools we use later that month. We're still using Pivotal Tracker, Github, Skype, etc, but there's a lot that has changed.
As much as we'd like them to be, all tools are not necessarily awesome, and Jeff and Tim's criteria for picking which tools to use is spot on. We've tried out a lot of things, experimenting with new tools and 'failing fast' (something else we love to do so we don't waste time) when something doesn't work right. It's pretty easy to get used to using something that is inefficient, or to spend all your time tinkering with new tools and gadgets and not getting any actual work done, so it's important to consciously bias towards simplifying your toolset. Here's some examples of things that we tried and scrapped.
→ Read More
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.
A Post by Erik Huddleston RIP: The Iteration 19?? – 2010 came across our desks last week, and it sound’s like he’s pretty serious in thinking that Iterations are a thing of the past. Please give his post a read before you continue onward here. You might also want to look at CBQ’s posts on Iteration Based Contracts and What Makes a Successful Iteration, as well as mine on Communicate early, Communicate often, but don’t repeat yourself!.
Erik should definitely use whatever tools and methods work for him, but at Highgroove, we love doing iterative development, Pivotal Tracker makes it easy to get it right, and we wouldn’t have it any other way! First up, some rough thoughts from some other team members:
They sound like they adhere to a script even when it isn’t working.
Adopting a “pattern” for the sake of using patterns has never been a good idea. Being an “Agile” developer is more about being Agile with your processes than using “Agile” processes.
They’re just abusing developers in another way and finding another way to make them miserable.
If something is forced on a team that makes people unhappy, productivity will go down and quality will suffer.
They’re clearly in an environment where developers aren’t smart enough to accept responsibility.
Everyone on a team has to be willing to stand up for themselves and for doing things the Right Way. If a company culture or manager blocks out this kind of feedback, or developers aren’t willing to speak up, it’s probably a sign of an Office Space sequel in the works.
Some of those are a little coaxed and are a bit harsh, but I think the underlying feeling is pretty accurate. Here’s some specific counter-points to Erik’s arguments.
by jonathan
Have you heard the myth about the lone wolf programmer? Knee deep in crushed jolt cola cans, empty latte coffee cups, and busted keyboards (due to the incredible work rate of their owner), this paragon of unheralded genius is an island of productivity and impressive tasks accomplished in insanely short time spans.
The phe-nom rides under the nom-de-plume of the cowboy/girl programmer. And the cowboy/girl programmer doesn't work at Highgroove Studios.
You see, we code review.
→ Read MoreI, 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"¦
Communication can be pretty tough, especially when people with very different backgrounds are working together to translate vague business requirements into a crisp web application. There can be e-mails, phone calls, Skype message, as well as messages that get posted to any of a number of project tracking services like Basecamp.
Without a plan, this gets out of hand really quickly. At Highgroove, we have a few very simple rules that help us get things done and deliver the best experience possible to our customers:
Most of our customers are pretty good about putting things that they want us to do into Pivotal Tracker, dragging and dropping them to prioritize what they want us to work on next. This is great because it keeps everyone in the loop and lets us look over past work and enables effective planning of when future work will be complete.
6am on a Sunday and you’re wondering about project status? Just open up Pivotal Tracker and you’ll know exactly where things stand, even if Matt has been up all night fixing bugs!
In fact, we’ve been using Github’s post-commit hook to update Pivotal Tracker stories automatically when we make changes to the code for a project. This means that when we fix a bug or implement a feature, a link to the details of the change automatically appears in the comments for that story.
That said, using a software tool can be pretty impersonal, so on to our second rule…
Talk to us on Skype, e-mail support@highgroove.com, or call us at 678.248.2440 any time you need something related to your project (or just to say hello!). We love to hear from you, and we’re here to answer questions and make changes to the plan for your project.
As soon as you get in touch with us, we’ll pull up your Pivotal Tracker project so we know exactly where things are. We put anything you ask us to do in a a Story, and tag things that we need something from you on with “needs-input”. If we answer questions for you, we’ll include the question and answers in the description or comment of the related story in Pivotal Tracker so that it’s easy to find again.
Everyone has their own preferred method of communication, so pick your favorite and get in touch with us. We’ll keep Pivotal Tracker updated with all the details so you’ll know that you’re getting what you’re paying for. If you decide that getting your pillow-pets ecommerce backend up and running is more important than fine tuning your space probe launching system, it’s just a drag and drop or a carrier pigeon message away.
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 chris
At Highgroove, we’re experts at glue. Not that kind of glue, but the kind that connects one technology to another.
We build on lots of great Open Source tools and libraries to deliver finished products to our customers that do exactly what they want. Without these pieces, we wouldn’t be able to do what we do.
For a project I’m working on right now, we need to be able to post to Twitter and Facebook on a schedule from within the application without requiring the user to push that ‘share’ button. The end result is something that seems like just two clicks in the UI, and isn’t much code, but took some thinking to get it working right.
So here’s what I put together, for you, for free! To those of you that put together the APIs at Facebook and Twitter, and those that worked on the Twitter gem and the OAuth gem, Thanks!
All the details aren’t there, but if you’re familiar with Ruby on Rails and working on a Rails 3 project, the code snippets there should be enough to get you talking to Twitter and Facebook. Let us know if you build anything cool based on those!
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 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.
The NYTimes.com had a fantastic article this weekend on The Rise of the Fleet-Footed Start-Up. Here at Highgroove, we have been preaching about being lean, building products agilely, and doing more with less for quite some time. It’s great to see a piece in the NYTimes.com Business section advocating this now-proven successful model.
…the lean playbook advises quick development of a “œminimum viable product,” designed with the smallest set of features that will please some group of customers. Then, the start-up should continually experiment by tweaking its offering, seeing how the market responds and changing the product accordingly.
Ready. Set. Iterate!
by cbq
One of the best features of Ruby on Rails development is the “Rapid Feedback Loop” that allows developers to quickly make a change and see right away how that new feature, enhancement, (or bug fix) behaves and looks in real-time.
This Rapid Feedback Loop actually becomes even cooler when you loop in the client — the product owner requesting a new feature or enhancement. At Highgroove, we do outsourced development and feature additions for many different projects. We’re always looking for ways to enhance that feedback loop with our clients. Here are few tools for quickly enabling an even more rapid feedback loop, that we can’t live without….
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.
Here are 4 reasons for prototyping applications first. By prototyping, I mean an emphasis on building working applications rapidly:
1. It is much easier to edit an existing application that to try to dream one up with nothing visual and interactive to work with.
2. Too much planning leads to over-complication. Sometimes you can be too smart for you own good. “What if the user wants to do X or Y.” Don’t guess, find out.
3. A working application that can be tweaked beats a theoretical application that is perfect (and either sucks when it’s “done” or never sees the light of day)
4. A Prototype forces you to focus on the core functionality, that makes or breaks your idea. Trust us, the logo is not your killer feature.
Credit is due to our good friend Mike Landman of Ripple for Reasons #1 and #3.
