NewSpring Maps
Lessons learned developing our first Meteor.js project
Every once in a while here at NewSpring Web we get to put aside our day-to-day tasks and spend a little time exploring new technologies and learning new things. This is something that is becoming more and more important to our team for a couple of reasons. First, it gets us out of the daily grind and gets our creative juices flowing again. Second, as developers (or as designers, leaders, ministers, pick your title), it’s important that we keep learning and growing. So why not build that time into what we’re working on, and create something useful and awesome at the same time?
With that in mind, we spent a morning brainstorming ideas and pitching them with the intent that we would have a three day “hack-a-thon”. We asked ourselves, “What is something that we could build, that would be beneficial to someone in (or some ministry of) our church, and have it done in three days?”
Say Hello To NewSpring Maps
What came out of that brainstorming session was NewSpring Maps. Our original intent was for it to be an experiment of sorts. A “proof of concept” to show that we could, indeed, build a solid app with the team we have, and deliver it in a reasonable time period.
The scope of the project at the time we started looked like this:
+ Framework: Meteor.js
+ Database: MongoDB
+ Map Service: Mapbox
+ Purpose: Plot campuses and the locations of households related to those campuses on a map.
+ Customer: Technically any NewSpring Staff member, but mostly Campus Planning and Development
+ Timeline: 3 days
Idea and scope in hand we jumped right into building our project that same afternoon, learning all about the Meteor framework as we went. Two days later we realized that this couldn’t just be a three day project. It had to be more. The usefulness of this idea to the people on our staff could be significant and we wanted to give them the best possible product we could. We never want to ship a half-baked project.
So our director extended the project a full two weeks. So the thing that started out as a three day “hack-a-thon” quickly turned into a full fledged three week project.
Once our deadline was extended though, we still functioned in full on “hack-a-thon” mode, never really taking the time to flesh out the project. What was the final scope? What are our timelines along the way?
Eventually, we did come to a consensus on a list of features that we’d like to ship with. But even then, the scope of the project still expanded to fit every last moment we had (and then some). The question “What else can we do?” was asked more than once.
Now, most of the time, project details are things I don’t deal with. But the more I got into this project, the more I realized some things about our project (and projects in general) that should be true in order to get a great project out the door.
What I’ve Learned
1. Finishing something on time and shipping is better than attempting to finish everything and never shipping anything.
Be willing to cut things in order to finish on time. Don’t end up ADDING things just because you think you have time. We’ve got to do a better job at seeing what really can and cannot be done in time and make the hard calls to cut things. We can always iterate the next time around.
2. Small timelines, small goals, ship often
Large timelines and large goals should be broken down into small timelines and small goals and then iterated on over time.
NOTHING should be added to a goal or timeline until the original goal is met and is ready to be shipped. Then you can look at adding other things. Even then, it should only be added if you can absolutely guarantee that you can still make your deadline.
3. Details will kill you every single time
The last 10% should be dedicated to nothing but details. Finishing touches take time. They are essential to a finished looking and functioning product. But they will kill you and eat you if you aren’t careful.
4. Test, test, test
We all test as we go. Which is awesome. But it’s got to be tested from a high level view regularly.
We’re biased because we’re working on it and think we know what things do, or how someone else is going to use our product. Chances are we’re probably wrong.
Give it to someone else to look at early and often. It’ll probably be some of the best feedback you’ll get. In a two week turnaround, that means at a minimum someone else should test what you’re working on at the end of week one and in the middle of week two when you’re getting ready to start on the details. You’ll still have time to fix any big things they happen to find before you have to ship.
Now granted, in a three day quick project, testing may not be super high on your list. Truthfully, it wasn’t even part of our original scope. But if nothing else, get with a couple other people and just share what you’re working on and show them how it works. You might be amazed how that little bit of collaboration can shed some light on the weak places of your app.
5. Everyone is different. Plan accordingly.
What I can do in two weeks is different than what you can do in two weeks is different than what someone else can do in two weeks. Adjust timelines, priorities, and work loads accordingly.
6. Celebrate the wins
What we celebrate we’ll replicate. Every step along the way make sure to stop for a second and celebrate how far you’ve come. Giving someone a high five, a pat on the back, or just telling someone that they’re a freaking genius will lighten the mood and encourage them as they move on to the next item on their list.
—
A Quick Note About Meteor.js
If you haven’t heard about Meteor, please take some time to read about it and play around with it. You can literally have a test project up and running in a minute. With a built in MongoDB, hot code pushes, and auto reloads of changed content on all connected devices without having to refresh your browser, Meteor could be a game changer. I think it’s safe to say that we really enjoyed working with it, and I’m just looking for a reason to use it again. Soon.
