1

This question already has an answer here:

Where I'm working, the developers changed every year, with each developer leaving his own way of doing things, and moving on afterwards, the code-base lacks proper documentation, is not developed with performance, or ease of migration, upgrade in mind, only focused on developing new features and fixing bugs.

Which puts me in an awkward position, the CTO changed once, and the current CTO is oldest one around the code base, if I have anything in mind to present or suggest it has to go through him, I thought of many things that could help from my point of view, but been holding back since the beginning of my employment out of fear that my ideas would seem far apart from the CTO's mind set or way of doing things.

How would anyone suggest a proper, and well thought approach of addressing this, my objective is to actually migrate the code-base from nodejs 4 to nodejs 6, rework the application architecture, and introduce nosql database, and maybe in the future migrate to micro-service architecture.

What I'm looking for is how to approach my CTO with a lets come together as a team and build scalable and new tech system upon the old attitude, As I intend to be there during the migration, and see this company step from one position to the next.

marked as duplicate by gnat, gazzz0x2z, Mister Positive, IDrinkandIKnowThings, mcknz Aug 4 '17 at 15:36

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • "Oh hi Mark, could we migrate to Node.js 6? It would allow us to do this and this whereas now we can't do this and this and have a more readable code since every developer had his own style" – sh5164 Aug 4 '17 at 9:04
  • 3
    Your main problem is not nodejs4/6, monolith/microservices, sql/nosql. It is the turn over rate whic seems really high. Changing architecture with developers still changing again and again won't bring pretty much any changes. – Walfrat Aug 4 '17 at 10:42
  • It seems so yes, and your point is valid, my team mate who worked here over the past year, building a lot of new components is leaving very soon, should that deter me from taking a different approach from the previous devs. or just carry on their legacy, which is not cool for me – Osama Salama Aug 4 '17 at 11:12
  • Do you have reason to believe your CTO wouldn't be receptive to your plans? You seem to be assuming that he'll be resistant to change purely based on his age which is a rather stereotypical and borderline offensive assumption to make. – Lilienthal Aug 4 '17 at 11:58
  • I didn't mention anything about his age, I mentioned oldest one around the code-base ( most experienced ), but anyway I approached him without in specific cases where we could use mongodb, he resisted this because of lack of AWS adoption on RDS for example, I approached about upgrading node.js reply was about unstable npm packages, which might introduce new bugs in newer features, thats why the code-base is under lock-down – Osama Salama Aug 4 '17 at 12:35
4

Actually your post contains two problems.

Problem A

... the code-base lacks proper documentation, is not developed with performance, or ease of migration, upgrade in mind, only focused on developing new features and fixing bugs.

The 1st problem is linked to the developers themselves. This won't be solved by upgrading NodeJS or using a NoSQL database.

What to do

The team needs to have some specific rules that each develop needs to apply while coding. Those rules should be created together or with a small part of the team. Talk to your manager and ask him to organize a meeting with the whole team. This will take some times to take place.

Problem B

... my objective is to actually migrate the code-base from nodejs 4 to nodejs 6, rework the application architecture, and introduce nosql database, and maybe in the future migrate to micro-service architecture.

Those can be good ideas depending on the projects and on your needs. Coming to the CTO and saying "Hey we should totally upgrade nodeJS and change the database" won't work. The answer will probably be "We don't have time for that".

What to do

Find the Why?. Why would you upgrade NodeJS ? Will it improve the speed of the application thus it will give a better customer satisfaction ?

For each proposition, you need to have an explanation and to show your CTO that this changes can give the team/customer/company a benefit.

When your ideas and explanations are listed and structured you will be able to meet CTO and talk with him.

  • I didn't go into the specifics of benefits of each proposed change, or how it would be fixing or changing the situation, my main challenge is not with issues vs solutions, or structure and listing them. It's with approaching a mentality that relied on a specific strategy in development for quite sometime, and what I want to introduce is an engineering approach to a measurable computing problem, and the challenge for me is how to get people on board towards developing our own internal strategy, that's why I'm more inclined to focus on solution to problem A – Osama Salama Aug 4 '17 at 11:53
2

Basically here you are trying to sell your idea to the CTO. For that to work you need to understand what does the CTO want to achieve in the long term.

What you are proposing seem like improvements to you, but they come at a cost and risk. Cost is developers availability and time, and risks are related to system downtime, migration itself and outright broken things.

You need to weight out the benefit of new architecture against the risk and cost, because that is what he will do. This is where your knowledge will come into play. For him to accept anything, you need to convince him that the improvements are worth developers time and possible risks. Now and and in the future.

0

Realize...

migrate the code-base from nodejs 4 to nodejs 6, rework the application architecture, and introduce nosql database, and maybe in the future migrate to micro-service architecture

"just because" can easily, and probably correctly, be perceived as merely contributing to the problem.

What you're asking is all that unusual though. What you need to do first is ask CIO for some time to come up with a plan to level the app around some predictable and common patterns and API's...which may not include the fancy new stuff... Realistically, consolidating around what's already used the most will give you and CIO the most benefit for least effort.

Not the answer you're looking for? Browse other questions tagged or ask your own question.