Recently, I received a company-wide email complimenting a few groups of people for excellence. Those groups worked hard together for a project and successfully launched it. There was this particular one praising about 10 people for giving their best and sticking it out for 6 months.

That, is freakin’ long.

I can’t believe anyone going through a lengthy project like that in these recent times. A console game, I can understand, and it typically takes about 2 years for a game to be completed. It’s extremely hard to correct mistakes after a console game is launched, so there’s a lot of coding and testing to do. I mean, how can one apply a patch after a game is out?

Start-ups are even more taxing. I was working in one such start-up software company, and the implied timeline given was one year. At the end of that one year, some product had better be launched and profits coming in, or the start-up company’s going under. Rent, programmer salary and flagging confidence of the entrepreneur will slowly drain the resources of the company for anything longer than a year.

The world is getting flatter. Individuals now hold as much power as large companies. Open source projects are on par with proprietary software, and sometimes at a fraction of the cost (some even free). Software management and development needs to move faster.

6 month long projects are just so last century.

If not for the fact that my company is large enough, I doubt that project mentioned above would have done anything to the bottom line. It would have taken longer to reap the rewards of that project. And sometimes, that’s a luxury smaller companies and individuals cannot afford.

6 months. 10 people to be paid. And nothing to be gained in between? Those rewards had better be good…

[start of small digression]
My colleague recently gave birth to a healthy baby girl (congratulations!). Nature has designated that 9 months is sufficient for a human baby to be fully formed enough to be born.

A baby doesn’t have to be born extremely clever. A baby doesn’t have to be physically strong. A baby just needs to be as complete as possible at the point it’s born, and have the potential to grow.

And no, that’s not my colleague’s baby girl…
[end of small digression]

How can a baby grow further? Be out here in our world. How can individuals, small businesses and large companies grow further? By putting themselves out here in the world. How can software grow? By being tested in our world.

All the documentation, design, coding, testing, meetings and discussions and opinions mean naught if the software doesn’t work in the real world. And you only know if it really works when it’s out here, in our world.

Faster iterative cycles

That’s why agile methodology recommends smaller and faster iterative coding and testing. Code, launch, test, get feedback, code better, relaunch, test again, get more feedback, and so on. Of course, there comes a time when launching into the real world works better than launching into a test environment. Well, release the software product, and get back to making it better.

Launch your software with as complete a feature set as possible, and as soon as possible. My users are usually ecstatic over a small launch into production, be it just a new interface that really helps their job, or a small web application catering to a customer need.

Why? Because with faster launches, they can garner more businesses at a faster rate. Sometimes, customers don’t need a million dollar application with 100 plus features (most of which will never used). They just want a 3-screen interface application that does a really good job of retrieving data, because that’s all the customer really wants. Anything else is fluff, nice to have but hardly earth-shaking if absent.

And when the application is launched, there will be real-world feedback from the customer, real suggestions and improvements to be made instead of the hypothetical business cases when planning the original million dollar application.

How do you get faster launches with your projects? Break it down into the smallest, most complete application that satisfies the requirements, and launch that. Then move to the next phase by implementing the next most complete superset of the features you cut out from before, and launch that.

In the process of doing this, you may find you no longer need some features, because then, you’ll really and truly look at what provides the most value for the customers and users from the application.

My real life example

There was this one project I did. My whole team had rescheduled everything else, because the customer was a huge deal, and the time given was one month. My users worked hard to obtain that customer contract. Sales people selling, customer service people servicing and administrative people administrating. My team was tasked with the IT part, porting data, managing data, calculations and processing. Me? I was in charge of the web application, the very interface that customer has with all that data.

During that period, I was in the middle of helping two teams with development work. Two teams, two projects. Torn between two teams and faced with looming deadlines, multitasking was definitely out of the question. I had to focus all my energy into completing one project before the other, because it’s the fastest way to complete both within the time period.

For my main team’s project, I had to come up with a fresh design from scratch, all by myself, and I had to make sure that it’s scalable. Knowing my users, they’re going to add more features so their customer remains satisfied and they remain productive. For the other, I had to do code reviews, code improvements and some documentation.

A one month deadline. Somehow, I managed to come up with a usable, scalable web application. Somehow, I managed to complete the development work for two teams. All in one month.

You know what? After the launch of that web application, my users started asking for more features. I’m sad, because I had to go through intense deadline cycles again. I’m also glad, because it meant the customer was satisfied, and my users found the interface useful. No corrections, just improvements.

Wrapping it up

Shrinking project deadlines forces you to think about the software, from requirement to design to code. Deadlines measured in months are for consultants. Deadlines measured in weeks are for real programmers.

Discuss.