Jake Pruitt

This is where I write.

← Home

Salvage

Salvage - JavaScript Jake

“Guys, I think we broke a record. We just completed 94 user stories in one sprint.” My project manager looked around the room after saying this with visible relief in his smile. The quality assurance manager added, “And you had them all in before the Tuesday code freeze. I don’t think anyone’s ever had a sprint like this before.” The lead developer and I looked at eachother and nodded, and I said, “It worked.”

We had decided to rework the entire front-end development process to use Grunt, Bower, Jade, and Sass. And in the matter of a two week sprint, with the help of a contractor, we were able to produce 13 pages of high-quality code, and complete 94 user stories.

We turned around a project that was not going to reach the deadline, and we broke records in the process.

A Complex Problem

Our project was intitially using Middleman and Bundler in order to support the Ruby asset pipeline that the lead developer used from a previous project. Middleman is a very good static site generator built in Ruby, a language that has had a lot of success and continues to be one of the largest communities on the web. Ruby has the advantage of being a very eloquent server-side language, and Middleman was a very good choice from the outset.

However, we were also trying to integrate a number of Grunt plugins for generating web fonts and increasing performance. We also were working accross multiple repositories in collaboration with an international team, and that international team was very specialized in working with Node.js tools like Grunt and Bower. Our system as it stood was going to have difficulty integrating with the German team, and we needed to find a solid solution to interface with eachother.

They turned to me to search for a better architecture for the project. I created 3 options for the project, and presented all of them to the team. When I turned it over to my boss to decide, he turned to me and said, “It’s your call, Jake.” It was the first time I had ever been given the responsibility of making an architecture decision, and I could not be more terrified. It was a tough client, a diverse team, and approaching deadline, and everyone was looking to me to see if I could handle it.

Re-wiring

I decided we should go with Grunt for the entire process, switch our templating language from HAML to Jade, and move all of our global styles into a Core repository, pulling them in as a dependency through Bower. Over the course of a very rocky sprint, we made the conversion, with unforseen issues arising from grunt-contrib-compass logging issues breaking IE8 and machine-specific issues setting up fontforge.

We now were at the end of sprint 4, and we barely had any pages to show for it, since we had spent most of that sprint trying to make the conversion. I was very nervous and considered my decision a failure, since we had wasted precious time just to move from one system to another. I began to doubt whether or not my decision had been right to move to Grunt and Bower.

At this point, the project manager was worried about the impending deadline and talked with us to figure out what we could do to find a solution. We saw no other option than to bring on more developers to the project, to add more man-hours to make up the ground we lost in the conversion.

The lead developer and I were worried about an influx of more developers. It is not always easy to bring on new developers to a project, and we feared that our time spent onboarding the new team members would take away from the little time we already had. But we knew it had to be done, so we sat down and thought about a good way to have a large team of developers working concurrently on a responsive front-end project. This truly would test whether or not the decision to go with Grunt and Bower would pay off.

Pre-flight

Halfway through sprint 4, we asked the designer to not build out any more page-level photoshop files, and instead just build one comprehensive styleguide, with every single component that would be used on the pages. We would then follow the general layouts of the wire-frames from the UX team, and snap together the components to build the pages.

We set up an individual jade partial and scss file for each component, and included them all in the styleguide. Each component had its own user story, and we assigned the styleguide accross the team, each person with their designated components. We committed sprint 5 to just building out the styleguide, and I was assigned to work with the international team to merge as many of our styles into a core repository that could be used accross both our responsive project and their microsite project.

We hit the ground running in sprint 5 with five developers working concurrently. The lead developer closely monitored all of the pull requests and tuned all of the styles to be as modular and consistent as possible. Each component went through quality assurance before the Tuesday code freeze, and we finished every component that would be used in the site. We didn’t know if this would work, but we had been forced into a position where we had no choice but to try something new.

And in sprint 6, it all payed off.

Hyperdrive

In sprint 6, we committed to finishing 13 pages, pulling in 90 individual user stories, which was one of the most aggressive sprint plans we had ever done. We knew we could handle it, since all of the components had been built and tested already, it was just a matter of composing them together in the pages.

The developer team had incredible velocity, working with the other team members’ components was every easy, and together with Foundation’s grid system, we not only met our expectations by the code freeze on Tuesday, but exceeded the goal. Upper management was thrilled, the client was blown away, and the international team was fully onboard with our progress, already using some of our components in their projects. The development team had never seen such velocity for two and a half developers in two weeks.

At the end of sprint 6, which was today, a company-wide congratulations and thank you email was sent out by our project manager. The executive-level managers were very impressed, and we knew that this process, which we chose out of necessity, worked incredibly well. With this success story, many of the projects in the pipeline are already looking into using our model for their development process.

If we could do it over

If I had the chance to do it over again, I would start with the core repository and build the styleguide components in there exactly like sprint 5. Then, with that repository set up to export a single stylesheet and a single minified JavaScript file, we would incorporate those into the actual website repository through Bower. We probably would have also tried to incorporate a more component-based architecture, possibly using Polymer, rather than subscribing wholesale to a library like Foundation.

How would you have approached this project? I’m interested to hear your thoughts! Let me know in the comments below, or @thejakepruitt on Twitter.