That’s a crap idea! or “What I learned to program my first app”

I find the greatest difficulty I have with having so many “great” ideas is following them through to completion. A few years ago my brother, Philip helped me to process which ideas offered the most potential. It basically followed these steps:

1. Shoot down all the positive aspects of the idea:

Find as many different ways that the idea can fail, guaranteed you won’t be able to think of all of them, but if you are able to get a substantial list you will have a bit more perspective on what is actually a do-able task. I’ve used pros/cons lists, SWAT analysis, Use cases and general brainstorming in a variety of mediums to eliminate some ideas that I thought really had potential.

2. Look at what is required to complete the ‘great’ ideas and figure out what you need to learn to achieve the project.

This answers questions such as;

  • Do I have the industry network/streamlined outsource access to suggest this idea and actually see results?
  • Do I have the skill set? What skills do I lack and how long will it take to learn them?
  • Does this idea fit into my future plans/goals?
  • What is the risk/reward of this project? -Be REALISTIC or failing that, be PESSIMISTIC
  • What is the estimated time frame required to complete this project? -If you are like me then you’ll always underestimate, but do this anyway… it will give you some sort of benchmark.
  • Where is my guru? -Who can help guide you through the learning required and the steps to implement this task?… I have Philip to thank for saving me many years of wasted effort. The internet can also be your guru, but be wary…. the internet is like Yoda: cryptic, misleading and written in bad english!

3. Which requires the shortest time frame to complete?

Pick that idea and see where it goes….

best of luck.
There are plenty of great ideas but not enough people to complete them.
An idea without action is worthless.

This entry was posted in Uncategorized and tagged , , , , , , , , . Bookmark the permalink.

2 Responses to That’s a crap idea! or “What I learned to program my first app”

  1. insanity says:

    A very handy list. One thing I would stress with the estimations is that there is a very large difference between “first rough cut” and “polished final product”. The difference is often double the expected estimation on various task sizes. Programmers often fall into the trap of “I think I can hack something up in a day or so”, which generally doesn’t include release issues, unit-tests, iterations required to fix problems etc.

    The best thing I’ve found to do is to break the task down into 0.5day tasks. Anything larger than 1day is likely to mean you haven’t thought about the task enough to figure out its smaller components (this scale is relevant only for development work. Project management tends to be a larger “minimum allocation block”).

    If you have never done a task similar to the one you’re estimating now, your estimates are going to likely be useless… so spend some time doing a spike first, to get an idea of what is involved (spike meaning a standalone spike ignoring most functionality. e.g., an android UI with no other logic behind it).

    And always remember… a functional product trumps code EVERY time. This isn’t an excuse to write bad or buggy code however (as this hurts your development time), but it does mean you should only polish as much as necessary ad no further. YAGNI & KISS are 2 very useful acronyms to help evaluate this.

  2. Admin says:

    Great thoughts! In my first year of uni they kept reminding us that over 80% of IT projects fail to meet that magic combination of on-time/on-budget and satisfy the customers needs. Disgusting numbers really.

Leave a Reply

Your email address will not be published. Required fields are marked *