Lunchage : The Beginning

When I first began using ASP.NET MVC as a web development framework, I found the Nerd Dinner application from Microsoft helped to learn the ropes.  The app though never really went far enough into an application’s development cycle to answer a lot of questions I had when starting a new project (to it’s credit though, that really wasn’t the point of the sample application at all).  Trying to find decent help on how to make design decisions can be found in the classic books (Patterns and DDD) but real-world examples are often made into smaller chunks without the big picture on display.  In light of this, we wanted to focus our energies to coming up with requirements for a brand new open source app and take anyone willing along for the ride.  Our open source application will function as a medium to present design decisions and challenges that we can publicly solve for the greater good.

Introducing :  Lunchage

We decided that since we like eating lunch so much and are indecisive, why wouldn’t we create an application that presented us with choices for lunch?  Ok, so right now you might be saying “Why are you making Urban Spoon?”, “Doesn’t Yelp do this?” or “You idiots really have nothing better to do huh?”.  To that, you’re probably right, but we have a few requirements that those apps don’t quite have.

So, over the next few weeks we’re going to be outlining the requirements, software stack, front-end necessities and design for the full Lunchage application.  I want to detail every thought and plan we have to show exactly how fast an app can be spun up using convention, agile methods and good design practices.  Through the programming process our range of blogs will cover object oriented design principles, modern front-end javascript frameworks, front end design and usage of HTML5, usability and maybe even mobile considerations.  The point being that we’re tackling a full scale operation and documenting the entire thing.

Requirements

Before we can get to coding anything, I’m taking the liberty of documenting the basic requirements for the team so we can all work off a unified idea.  Keeping with the Agile methodology, our requirements are going to change as we build and play around with our application so we try to keep any ideas we have loose so we can drop, defer or re-prioritize them at any time.  In my experience, creating a gigantic set of software requirements and sticking to every crossed t is a fast way to create an expensive, complicated and bloated piece of you know what.  Agile aims to keep not only the software cycle lean, but the requirements themselves.

The basic idea of our application is this: I want to log into the Lunchage application, select one to a few descriptors of food I want to eat and I want places in the area to show up.  That is all.  Any other details we add is just fluff.  Our software is going to be designed to perform one very specific task very well.

Now that we have our basic concept, other details we know we want are the ability to log-in using at least two major authentication providers (Facebook and Google for starters) and we want to be able to connect with other people in our application to share where we are having lunch for others to tag along.

The other implementation details (i.e. where we get restaurant data, do we want reviews?) will be discovered as the application is built and discovered.  The main point is that we don’t want to spent a significant amount of time and money on features that we don’t end up using.  Remember the 80/20 rule!

To finalize then, I want an application that:

1. Let’s me sign up with Facebook or Google
2. Let’s me pick food types like “Chinese” or “Spicy”
3. Gives me local places to have lunch.
4. Allows me to share that lunch choice with friends.