In this short video we fall into the madness of software development.

▶️ Watch on YouTube

I’ve been working on a light-hearted series of videos talking about crimes against software and causes for over-engineering.

Brainstorming

When working on our projects, it’s normal to overthink what the product should be or the features it will have.

Thinking about the long term usage can lead to over-engineering the architecture or over investing in external services. It could be that our high expectations fuel the belief that there will be a zillion users signing up and we have to build a product that holds up. And it might be that we are not fully aware of the actual processing and maintenance cost of what we are creating, so we just decide to use a technology that promises to scale automagically.

Another reason to make things unnecessarily complicated could be our desire to build something elegant. The concept of what is an elegant implementation can be very biased. It can be affected by the notion that some current technologies are the standard and if we don’t use them we are building it wrong. And it could be that we decide that a simpler solution is just not professional enough. Not having access to all the shiny graphs and colorful buttons could make management and investors worried and consider the product a black box (fear of external influences).

But underthinking is also a trap. Not having a clear understanding about what the product is and will be can make us lose focus and imagine a bigger puzzle than it actually is. Down the rabbit role we go trying to be inventive and disruptive. The unknown is exciting. The other is boring. We imagine users will be flabbergasted by our monstrous creation. But what about our team? Can they decipher the beast? Will they be able to tame it?

From the perspective of architecture:

The cons and pros of making a monolith vs a distributed app. (I’m biased towards monoliths).

A monolith might take more time to develop and launch (not convinced) and the cost for zero users will be higher but significantly lower with thousands. In the future, if the product gets traction, it could mean cheaper costs and more freedom. Security could be an issue depending on the team expertise.

On the other hand, it can be easier to build a product using distributed services, but it’s gonna cost way more in the future (and the stories of people that see hundreds of charges on their credit cards because of a mistake or api abuse). It can be chaotic to modify the product on the fly and remove external dependencies due to cost. It usually requires more maintenance due to apis changes. And it introduces the culture of spinning up a new server instead of improving inefficiencies. (I just neeed to make this reference silicon valley s02e10).

Some questions to figure it out:

  • What is the size of my team?
  • What kind of product am I building?
  • Is it a fail fast mindset?
  • Is it a free subscription for life or a trial period (affecting infrastructure costs)?
  • What are the imposed limitations?
  • How much money do I have right now to keep the lights on?
  • How confident am I that the product is going to fail?

Credits

Script

The edit

The edit