How Two Men Delivered a Baby in 4.5 Months

how-two-men-delivered-a-baby-in-4-5-months-0

Every once in a while, we get a request out of the ordinary, and just sometimes we take the challenge. This is a story about one of those times when two men delivered a baby in 4.5 months. Figuratively.

Almost everyone working in software development eventually gets familiar with Brooks’s law. Another way of putting it is

Nine women can’t deliver a baby in one month.

Hence the figure of speech above. There are exceptions, of course, and this is one of them.

The quest

The Holy Grail is in that castle, along with some obnoxious French

To conquer the unknown, of course. Long story short, we were given an opportunity to help out on a project that was late before we even started. The details were scarce, the job was on-site with the client at the other end of Europe, and the deadlines were just around the corner. After a quick round of negotiations, the deal was set: two men for four days, working on a big app that was yet to be released to the public.

The resolution

Skipping ahead to the end – well, it worked. We gave the project a much needed push in the right direction and set the grounds for working on it from back home. Looking back, I don’t think I ever doubted we would pull it off, despite the odds looking grim on paper.

Happy programmers in action

Programmers in action

So, why the lack of concern, and even more important, why did things work out well?

For starters, a lot of mobile apps are in the scope of 1-2 developers to handle. Usually a single developer should be competent enough to handle an average app by himself, not including the API or other components outside of the application. This was the case here as well, with most of the work being done by a single developer, so initial project assessment took a negligible amount of time.

There was also the pressure to do what we were hired to do. Some people don’t respond well to increased pressure and lack of time, but in our case this probably added the much needed sense of urgency.

Isolation and focus can boost productivity drastically. Working on-site, with very little to worry about other than the project at hand, we could afford to concentrate completely on a single task that needed to be done at that moment.

Experience was also a key factor. This wasn’t our first rodeo, so we knew exactly how to handle certain situations. It was just a matter of coding the right solution and not wasting time on figuring it out.

The challenges and lessons

A lesson lived is a lesson learned

After working on the project on-site with the client, I brought it back home to work on it full time. There were quite a few hurdles to overcome with the combination of working on-site and working remotely, but it essentially boiled down to these:

  • Working with other people can be challenging if they’re not a regular member of your team. Get to know them and find common ground and a good way to work together.
  • Every company has its own development processes and prefers different tools. It takes a bit of time to fit into a different workflow (or even help someone ditch their workflow in favor of a better one). Switching to a newer or more suitable technology is often a short-term pain that proves to be worthwhile in the long run.
  • Sometimes, perseverance is the key. More than once, the issues kept piling up, but working through them was just a matter of persistence and systematic problem solving.
  • Developing a location based app while not being at the location turned out to be a lesser challenge than expected. A bike is a really versatile transportation method for simulating different conditions.
  • Skype meetings are mostly fine, but in-person meetings every now and then can give you a positive boost.
  • In certain scenarios, pair programming is a very effective technique. For example when a new programmer needs to be quickly introduced into an existing project at a later stage of development.
  • Always check the weather before traveling and dress accordingly.

The last one is probably the least significant for this article, but sometimes the simplest advice is the best advice.