Continuous Thinking: Nerdbeers Continued - We All Win !!

Note: This post is the successor to the previous post on NerdBeers; if you have not read it yet, you might want to browse through that one first in order to have some context for this one.

Introduction

The initial development on the Nerdbeers app was started about two weeks ago, and I never imagined it to be such a big thing really; I just wanted to build a small app to prove to myself that I could write an app without falling in the usual architecture trap.

But things evolved quite a lot, or, to quote a famous book:

"Opportunities multiply as they are seized"
Sun Tzu - "The Art of War"

I will try to give you a short overview of the key things that happened in the past two weeks.

The Components Matched Perfectly

As I had been reading around on the web about Manos, Kayak, Massive, lean software practices, getting things done, ... I was looking for an opportunity. The main focus point for me was avoiding protocol/boilerplate code, and thus having as much functionality as possible while writing the smallest possible amount LOC (Lines of Code).

The minute I saw the Nancy web framework at github, I knew that this would have to be it; it had such a nice and clean syntax, and it was similar to the thing I had been thinking about building myself. After one of the main coders provided the idea of re-implementing nerddinner, I just started implementing it.

Doing this, I did notice that I needed some kind of a data access layer as well. Looking for the ultimate LOC/efficiency, I opted for the relatively new Simple.Data, which looked like it was the tersest possible approach to data access for me.

They matched perfectly!

The Components Were Really Young OSS Projects

Since both of the components were still in an early development phase, they were bound to have at least some bugs, so choosing a relatively new player on the block might seem like a stupid mistake to make, but in my opinion, this was one of the best decisions:

By choosing very "young" open source projects,
the contributors were all willing and able to help me out 
with my newbie issues in a very direct way.

Think about it: if you use a mature Open-Source component, the OSS contributors get flooded with support requests, and are probably being asked the same questions over and over again. If you choose a young project, the authors will probably notice your questions and they even might be able to help you out directly.

While I was hoping for some help, I never expected such a massive amount of response.

The Component Authors All Contributed a Huge Amount to the NerdBeers Project

What happened here was way beyond my expectations: next to getting almost instant help from all the component authors over Twitter, they even started looking at my code, telling me what could be improved, and they even launched a few pull requests.

Most of the "bugs in their components" were actually bugs in my app due to my malpractices, but they were always there to help me out.

They also liked the fact that Nerdbeers was an implementation which showed off the results of their labour.

After numerous amounts of tweets with @GrumpyDev, @TheCodeJunkie @MarkRendle, and others, I finally had an app boilerplate ready.

Next to this, someone from appharbor (@troethom) helped me to resolve a "bug" in my solution so that I could deploy the app to a demo website (for free), and the maintainer of AutoTest.Net (@AckenPacken) was there to help me after a tweet, even though I just made a stupid mistake (using the wrong MSpec runner).

The NerdBeers Development Team - a.k.a. "Wow, It Really Does Happen!"

Here is a confession:

Without all those brittle minds, this would never have happened.

I have had projects skyrocketing in the past during my professional career. In my honest opinion, the usual way to get this happening is following these steps:

1. Think about an idea
2. Care about it, grow it, be passionate about it
3. Set an initial target: both in scope and time
4. Start implementing it
5. Ship it at the time you planned it - really early, no matter how bad it looks, even if it does not have any true functionality yet
6. Get other people passionate about it, and try to trigger their interests
7. Go to step 1, hoping to have at least triggered the interest of a few persons who might join you in the process later on

If you want this to happen, I can tell you one thing in advance: it will be hard, you have to be really persistent. You will have to take shortcuts, make some tough decisions, and be prepared to take the blame. It also requires some experience in team lead, group dynamics, NLP, management techniques, sales techniques, especially for step 6.

If you manage to pull this off, you will notice that the team's interaction augments the individual team member's achievements to a new high.

For Nerdbeers, step 6 happened naturally; it did not take any effort at all. Agreed, there was some persistence required for the first steps, and sending out a version like this might have even damaged my "being professional about software architecture" (LOL), but at least I got something out there.

Here is what happened: the people started caring. No effort from my side was required at all. Those people influenced other people, and those might actually influence other people. All by themselves, no extra effort required. While this might not be a "traditional" software team, I would still call it a team. Agreed, we communicate over Twitter, instant messages, github, without having any real contacts, or even some kind of direction, but everybody cares and takes his responsibility. Which is great, especially so soon in something so small !!

Conclusion & Things to Consider

After two weeks in the project, we have progressed a lot. We still have a long way to go, but I am confident that we will get there. For me, the journey is more important than the destination, and I have had a very interesting journey already. It kind of makes me wonder of the path that lies ahead of me.

The app in itself is still pretty useless, but the real value is in the way it has been constructed, both technically and on a social level.

This experience also makes me wonder about the future of software development teams. As far as I know, everyone on the N-team has day jobs. We do not share a common language or country. Yet, we still manage to be quite effective in handling problems quite efficient.

This makes me think about my future projects. As a small ISV, I currently have to turn down some projects, because they are too big for a single person. Working like this makes me wonder whether I might be able to take on a bigger project, working in the same way as we did on the NerdBeers team, with people whom I trust from previous experiences. We could sit together in an office, but we would not need to.

Maybe that's what work 2.0 will be about: a truly global work environment in the comfort of your own home.