Bleeding-edge VS. Stable

This post refers to my experience as a Software Engineer but it can probably be translated to other scenarios.
If you’ve been exposed to software development in the last years you might have noticed the hype process speeding up.
With the market of application development skyrocketing,
and with the usage of FOSS as building blocks,
some of these packages have raised to fame.

All of these modules come with the proposition to solve a problem, and some of them do,
but with any decision to apply a certain language, framework, etc. comes some binding.
The most important is probably the investment in terms of time.
Have you ever found yourself in the position where one of the key dependencies in a project starts to wiggle?
I have, many times…

And the feeling is always the same, another poorly maintained (and financed) project that needs to be replaced.

But how did we get here?

There could be many reasons:

Feeling the Hype

When you start a new project, the greenfield scenario is valuable.
As an Engineer even more, maybe you’ve been working with the same stack, and all of a sudden you get to choose the stack.
It doesn’t happen often, therefore it’s a chance to try the new technologies you’ve heard about.
Given that we have enough time this is a good thing, experimenting is required for growth,
but then something unpredictable may happen due to poor library support.

Time goes by

How many stories have you heard of important open-source repos being archieved?
If we got to this fast, chances are we’ll move away with the same speed.
It’s hard to predict what will stick and grow.

Free as free beer

I love it when a employers mandates that its staffed developers shouldn’t contribute in solving open source problems, but then create projects using open-source as the backbone.

(Not my current management, they are awesome :D )

Most of the times some people expect things to work but don’t really know what’s under the hood,
their mantra is to use out-of-the-shelves tools in order to optimize resource spending.
And then you find the project sitting on a time bomb, and dev time is burnt because of rotted dependencies.

---

The scenario above can be quite dramatic, but lets not be negative,
Most of us get paid to solve problems.

Old is the new New

I’ve played with many high level languages, and implemented common patterns endless time.
Everything I do does NOT rely on one thing, the tools I use have many similarities.
So there must be a way we can avoid getting stuck with a dependency

Curiosity killed the cat

This is true for me, an it could also be for you…
I’ve spent lots of time doing/learing the wrong things.
Optimizing where we want to invest resources is hard, and sometimes wandering is also helpful,
but going back to the fundamentals is something I always do from time to time,

Back to basic

Getting the basic right is just too important, and this is foremost the pricipal issue of the screwed projects I’ve been part of.

Lets talk programming languages, the web development trend is to use Rust.
Awesome language, it was created to work on operating systems, with the aim to make system programming safe,
and to avoid some pitfalls that have been caused by wrong C/C++ implementations.
The interesting thing is that most of the people that use it for web development have very little experience with C.

I would argue it is being overused these days.

At the end, it need to work

The example I’ve made above hopefully passes the idea,
BTW in a world of evolving programming languages Rust will probably one that will stick around more than others.

But hopefully it gives you some context to my argument,

lets stick with stable technologies rather than going all in on bleading edge.

---

Think differntly, reach out and lets fight.
If you got this far thanks for your time…