3 Project development fallacies that we make.

I want to outline a few fallacies that are born in the phase of Product Development. Fallacy #1 It is easier to build in chunks because they are smaller.

3 Project development fallacies that we make.

I came across this comic from Toggl in which it shows the creation of earth from the point of view of a Programmer. I will be adding the comic at the bottom.

While reading the comic, it came to me that it does not only depict the faults of the programmer but of Management, Product Design and the whole cycle of Development, but in this case, one person was responsible for all. Of course, the outcome is very tech related but I hope to explain it to everyone.

I want to outline a few fallacies that are born in the phase of Product Development and it would be great if you can share also what you think in the comments.

I advise you to read the comic quickly to have a reference during the rest of the post.

Fallacy #1 It is easier to build in chunks because they are smaller.

If you read the comic, apart from the few giggles it gave you, you realize that this is not far from most projects. We started off with big task create the earth, that starts quite simply in a brick to brick approach, adding one requirement at a time with the main concept that this is easy.

Each task is small, concise and should not cause problems during development.

However, the truth is, that no matter in how many chunks you separate a project into, if the boundaries, the connections and the behavior between them are not defined properly, it will never work.

Chunking helps distribute the load over your resources, however, it can lead to a big mess if there is no proper planning beforehand. Moreover, there are tasks that cannot be split further.

Fallacy #2 If we use this methodology, we will work better

This fallacy is derived from the slide in which all the problems are attributed to the 'Flat Earth Design', essentially pointing the finger to either the technical architecture or the product management framework.

However again there is no 'One' methodology that will ensure success for your project. On the contrary, most likely any methodology will yield results but might suffer in terms of development speed, flexibility etc.

Only accept a methodology that suits your 'style'. A multi-million company that employees thousands of people and a small 10 man startup cannot have the same requirements and therefore we should rethink, was the problem the methodology or the execution?

Fallacy #3 We shouldn't use this technology because Toggl comic said is bad

In the last slides, in a bit of exaggerated humor, the author compares MongoDB (a database program) to the forbidden apple/snake found in Eden by Eve.

This is a heavily personal opinion, and I believe it is based on the few months old events, in which security researchers and malicious hackers exploited the default setup of MongoDB to make money from companies.

The issue, in short, was that the default setup left ports open and accessible to everyone, in layman's terms this is the equivalent of buying a house and there is no door. Although this example is not the best, would you really blame the architect if your house got robbed when you were ok with leaving the door out?

Same thing happened in all those MongoDB instances. Developers ignored the default configuration, did not spend 1 minute to read the security walkthrough by MongoDB on how to strengthen the application.

Our opinions should not be formed based on generalizations, word of mouth etc. We must take our time to investigate before coming to a conclusion, which can lead to surprising results.

Not every company that uses MongoDB got 'hacked' and many have found it as the golden hammer. It's up to you to decide.

A fallacy is the use of invalid or otherwise faulty reasoning, or "wrong moves" in the construction of an argument. A fallacious argument may be deceptive by appearing to be better than it really is.
3 Project development fallacies that we make.