Why your first app will fail

So you have just learned your new shiny language (or a couple) and now are wondering what to do next. For most, the options boil down to

  • Join a web development agency (get employed)
  • Become a freelancer
  • Create a new product and sell it.

If you are like me, you probably jumped right into no 3 and started coding your ideas. Hours will be burnt as you toil for many hours at a go until you finally have your product for publishing.

You publish your product on the app markets (if thats what you are into) or buy up a domain for your web app and start drumming up support all the while waiting for users.

Then it happens, Nothing. Not even one single user. What could have gone wrong?

Dunning–Kruger effect

You have just been hit by the Dunning-Kruger effect (D-K)!

The definition according to wikipedia for the D-K effect:

“The Dunning–Kruger effect is a cognitive bias in which unskilled individuals suffer from illusory superiority, mistakenly rating their ability much higher than average. This bias is attributed to a metacognitive inability of the unskilled to recognize their mistakes.”

Now I know you are probably that can’t be right, besides you can’t think of an application that you can’t engineer in you chosen language and you have practically read all the marketing blogs you could get your hands on.

Well unfortunately things are just not that easy and some of the following factors have certainly been playing again you:

  1. You will sub consiously over emphasize on the particular area of expertise that you are good at: For example developers good in scoping and requirements will come up with a very detailed SRS (Sofware requirements document) while those skilled in database design will create great designs but fail to focus on the user experience and so on and so forth.
  2. Feedback will be hard to get: If you have had to maintain someone else’s code or even your own code, you know how much more effort it takes to understand and process it. Couple this with the relatively low number of professional developers, you find yourself in a case where no one gets to see your code and its weaknesses, therego you never improve.
  3. You are smart and you know it: Most developers I have interacted with fall somewhere in the higher end of the bell curve. This probably served them well through their formal years of education. However you (the developer) will very soon realize that while raw intelligence counts for some, market experience counts for so much more, unfortunately it takes a flopped launch (or several) for you to get that.
  4. Low barriers of entry: This probably did serve you well as you we’re starting out. No one cared about your credentials and tutorials we’re a heap. Fortunately this resource is available to all other devs unfortunately most will just never use it. Thus you will have a lot of devs who couldn’t do the fizzbuzz test have already had a run in with you future clients. This is bad because by now they have already developed a negative stereotype to new devs.

Suggested ways to beat it

Here are some of my ideas on how to successfully navigate the muddy waters of D-K.


  1. Join a team: If you are a natural extrovert this should be easy however for the rest of us introverts this may take some effort. By joining a team, most of the problems I highlighted will most certainly disappear. If you don’t follow any other advice below, Follow this one.
  2. Give back to the community: Not every project you make needs to be commercial. Open source it! Yes it took time to make but the feedback about the quality of your code and the improvements that can be made will improve your worth as a developer dramatically.
  3. Help new developers: It may seem like a give-give relationship but in reality you may actually be getting more than you are giving. This is because by teaching you are forced to test the assumptions of all that you think you actually do know.
  4. Think small: If you have attended some formal training, you have probably been drummed with hype of huge pay. Even if you are an autodictat you have probably read success stories. The reality however is that what made this entrepreneurs rich was not their first project, something in the range of the 100th or worse. As such don’t pressure yourself too much, you will eventually make it but for now, build light applications and get them coming fast. This will help you build the necessary experience for your big one as well as allow you ample time to make the mistakes that will undoubredly show up.

The more discerning reader may have noticed I have mentioned nothing about spending more time coding your heart away. There is a reason for that. This industry just like all other industries is all about the people.

Your ability to connect with other developers, engineers, designers and most importantly clients is what will truly set you apart.

Thank you.

Other resources

  1. http://computer.howstuffworks.com/5-internet-entrepreneurs.htm
  2. http://www.codinghorror.com/blog/2007/01/how-to-become-a-better-programmer-by-not-programming.html
  3. http://opinionator.blogs.nytimes.com/2010/06/20/the-anosognosics-dilemma-1/?_r=0
  4. http://www.codinghorror.com/blog/2007/02/why-cant-programmers-program.html
  5. http://techeclipse.com/2013/04/10-richest-technology-companies/

If you liked this post and would like to recieve more please click on subscribe and like our page.




Resource Intensive PHP Tasks part 2

The requirements

Like the good developers we are we will kick of things by defining some requirements to help us in the design process.

But first some definitions.

Controller: PHP Script that directs receives and responds to requests

Worker: PHP Script that carries out resource/time intensive task

Model: PHP Script that provides the data framework. This can be anything from file system to the DB connection.

With that out of the way here are our requirements:

  1. System must respond within 5 seconds
  2. Controllers must not under any circumstances run for more than 30 seconds CPU time.
  3. Controllers should be able to report progress
  4. Controllers must be able to run on shared hosting service
  5. Workers must be able to operate independently.
  6. Workers should never have to interact with the file system.
  7. Workers should be easily exportable
  8. Workers should be RESTful
  9. Workers should have one verb to accept work. Common convention is to call this verb fire or index.
  10. Model must never return system resource handles
  11. Model must provide expected value types even on failure


A fair lot of the requirements are self explanatory. If you would like me to expound some more on any of this please comment as much below. Otherwise it will become obvious why we have the requirements in a bit.


Next article we will look at a sample work flow and the request life cycle. We will also get to see the relationship between the objects in our system.

by Jacob Chencha