Photo by Luke Peters on Unsplash

As a developer, we are focused on tech. We adore working with new technologies, languages, libraries, and frameworks.

All these things are changing so quickly! Are there any developers wondering what the consequences are for the business? Or the responsibility for a manager only? I don’t think so!

Every time I use the term framework, you could replace that with a library, programming languages, or anything in that line.

---

Scenario

A lot of developers that are working for a company (or more companies) are going to recognize this scenario.

We Need To Change To Another Technologie

A new JavaScript framework is rising in popularity. More and more companies are shifting from the X, Y, Z framework towards that new thing. One of the senior developers is proposing to take a look at that new technology.

After trying it out, the developer comes back with the team and their manager with his conclusion.

THIS IS EPIC. It’s smaller, faster, and has a new way to render the DOM with the UNICORN DOM (I made that up 😅). He convinced the team and manager that they need to dive into this framework; otherwise, they will lose clients.

We all have seen this scenario

If you haven’t had this scenario at your job, you probably have experienced something like it.

This is not all bad!

But typically, this has been analyzed from a technical standpoint. It is essential, but should it be the primary decision driver of choosing a new technology.

What are the consequences?

The consequences and questions that should be asked should be something like this.

• Everything that the clients are using has to be rebuilt.
• Since estimations are complex by default, it’s going to take much longer
• In the meantime, maintenance has to be done to the production software as well. But every developer wants to work on a shiny new thing.
• Maybe not all new features supported by the “old” framework are in the new framework yet.
• Are the users going to notice the better performance?
• Is everything well documented?
• How easy is it going to be for less experienced developers?
• Automated tests are deprecated by default!
• and so much more uncertainties…..

So many things are uncertain when picking a new technology! But still, so many managers and entrepreneurs are becoming excited by their developers that they underestimated their decisions.

So what should they do before getting hyped up by this new technology and steering the company blind?

A while ago I found a great post “How Zen Coding Can Lead to Better Programming” by Josef Cruz which I highly recommend to read 😉

---

What Is The Most Important To Keep The Business Running?

Okay, one of the developers in your team has the idea of switching everything up to this new framework. It looks good and very promising, but what problem does it solve? Are the users going to see and feel an improvement?

Problems to solve

Are there any problems the current application(s) has?

No: Then I think it won’t be an intelligent decision to change towards that new framework!

Yes: Then it is good to document the main problems, issues, and challenges this current framework has.

It is a perfect idea to document what the problems are with your current system. This helps to make it physical instead of something in the minds of people.

If you’re not going to solve problems? Then don’t do it! You are spending money that you should have to spend wiser!

The Business Needs To Keep Running

Okay, you have to build a document with all the issues your current system has.

Investigation

Now you can investigate if that new framework is going to fix a big part of those issues. It’s not strange to do this type of investigation. From my experience of the last five years of working with large companies, they investigate a lot.

Prototyping

Next to the investigation, it can be wise to do some prototyping. Maybe there are smaller applications in the company that won’t disturb the running of the business if they get replaced by new ones.

Only prototyping with the simple famous todo applications is not enough, in my opinion. But that’s also based on the application you eventually want to replace.

It’s also important to check the Github issues or Stackoverflow questions of that framework. This will give you a feeling of the problems, how difficult it is, and what features are still in the development phase.

But the most important thing is, keep the business running.

MVP

Maybe the prototyping phase wasn’t successful, so you have to go back to the investigation. What tool, technique, or library is going to help with solving the issues.

When the prototyping phase is a success, it’s not a guarantee that the development phase is a success. It’s a good idea to start with thinking about the minimal set of features that a first version should have so that the user can do most of the things with it.

We call that an MVP. Planning is essential with this phase! Yes, I know, planning everything wouldn’t be agile 😉! But do effective planning doesn’t mean it’s going to be a waterfall.

Excellent planning will help determine what features need to be built first and what doesn’t go into the MVP.

Make sure that you and your team take the time with this phase because it’s tempting to build instead of properly plan.

It’s going to take a lot of time

Think about how long it took to build the current production version of the application. A few years? Well, then probably this is going to take a few months as well.

Don’t rush through all the features. Take a reasonable amount of time to think about the architecture.

And if things don’t work out as planned, please don’t re-do the whole thing (I’ve experienced that a few times, it’s not fun for the business and the developers). Just look at it as a progression. It takes a lot of tiny steps to walk a mile.

Technologies are not the top priority

For developers, technology feels like a top priority. As a developer for a decade, I can agree that most of the time, it feels like that. But remember, no clients === no jobs. So make sure that the technologies make sure that the clients can do their work the best way they could imagine.

Client’s don’t care if you are having a scalable architecture or a monolithic application. They want to do their jobs faster than they did before! Because at the end of the day, clients pay the bills.

---

Conclusion

Okay, we know, as developers, we love new technologies! But if you don’t think carefully about this with the customer in mind, we are using precious time and money of our customers.

Let’s be more careful about decisions that involve a complete rebuild of the application. We all know it’s going to take 2x, 3x, or 10x longer than estimated.

Many tips above are coming from my own experience, so I hope this helps even a few of you!

---

Thanks!

I hope you learned something new or are inspired to create something new after reading this story! 🤗 If so, consider subscribing via email (scroll to the top of this page) or follow me here on Hashnode.

Did you know that you can create a Developer blog like this one, yourself? It's entirely for free. 👍💰🎉🥳🔥

If I left you with questions or something to say as a response, scroll down and type me a message. Please send me a DM on Twitter @DevByRayRay when you want to keep it private. My DM's are always open 😁