351–360 of 704 posts
The team will be able to try out how good programming can be and perhaps support you more. From there you should gradually move the old features in the new system. Even if you were to never fully complete the refactoring the situation would be much better.
A lovely knot to unravel! First, get everything in source control! Next, make it possible to spin service up locally, pointing at production DB. Then, get the db running locally. Then get another server and get cd to that server, including creating the db, schema, and sample data. Then add tests, run on pr, then code review, then auto deploy to new server. This should stop the bleeding… no more index-new_2021-test-jo…
I think this is bad advice, just skip it.
I would make a fresh copy of the production DB, remove PII if/where necessary and then work from a local DB. Make sure your DB server version is the same as on prod, same env etc.
You never know what type of routines you trigger when testing out things - and you do not want to hit the prod DB with this.
First off, no, a full rewrite is not only not necessary, but probably the worst possible approach. Do a piece at a time. You will eventually have re-written all the code, but do not ever fall into the trap of a "full re-write". It doesn't work. But before you re-write once line of code - get some testing in place. Or, a lot of testing. If you have end-to-end tests that run through every feature that is currently used…
Earlier quoted context omitted.
The problem with people new to the company starting a rewrite from scratch is that they often are poorly informed on why things were the way they were before. If you start big, you can have bad outcomes where the new system might be objectively worse than the old one... but you are stuck trying to get the new thing out for the next 5 years because too many people sunk too much political capital into it. As an example…
> why does our tracking pixel return a purple image? Now I'm really curious, is there some exciting non-obvious reason for a tracking pixel to be purple? Was it #FF00FF or more like #6600DD?
In fact, until OP can give us the right answer, we immediately need even wrong answers!
You reading this. Yes, you. Give your best wrong answer below.
2. You say you don’t manage the team. I guess you have some kind of ‘tech lead’ role. I think to get things to change, you’re going to need buy in from management and the team. If the budget is tight it will be harder to say ‘we need to invest in fixing all this stuff instead of whatever it is that actually makes money’. Whatever you do must have a good business case. It sounds like there needs to be better communication about the state of things with whoever in the business unit came up with the aggressive roadmap.
Perhaps a roadmap like this would work:
- First, set up source control and separate prod from however people are developing things. Hopefully this will reduce trivial outages from people eg making a syntax error when editing prod. I think this will be a difficult fight with the team and management may not understand what you’re doing. You’ll likely need to be ready to be the person who answers everyone’s git questions and un-fucks their local repos. You’ll probably also want some metrics or something to show that you are reducing trivial errors.
- I think some intermediate stages might involve people still developing in prod but having source control there and committing changes; then developing locally with a short feedback loop from pushing to running on prod (you won’t get but-in if you make the development process slower/more inconvenient for the team); then you can hopefully add some trivial tests like php syntax checks, and then slowly build up a local dev environment that is separate from proof and more tests. At some point you could eg use branches and perhaps some kind of code-review process (you can’t be the only person responsible for code review, to be clear)
- You’re going to want a way to delete old code. I think partly you will be able to find unreachable code and delete it but also you’ll likely want a way to easily instrument a function to see if it is ever used in proof over eg a week or two.
- Eventually, improving the dev environment enough may have already led to some necessary refactors and you’ll have enough tests that the defect rate will have decreased. At some point you’ll hopefully be confident enough to make bigger reactors or deletions and wean people further off messing with prod. For example moving some routing, bit-by-bit outside of nginx or perhaps using some lightweight framework.
- you should also get the team involved in making some smaller refactors too and they should definitely be involved in adding tests.
- team is 3 junior people
- productivity is abysmal
- budget is tight
- resistance to change is huge
- aggressive roadmap
- management and HQ have no real understanding
I have never walked away from a technical challenge, but I've exited from management clusterfucks and have never regretted it. These people will block you, blame you for anything you break during the refactor but give you no thanks if you fix it (because they don't even understand the scale of what you're trying to fix)
Earlier quoted context omitted.
> why does our tracking pixel return a purple image? Now I'm really curious, is there some exciting non-obvious reason for a tracking pixel to be purple? Was it #FF00FF or more like #6600DD?
This definitely needs an answer. In fact, until OP can give us the right answer, we immediately need even wrong answers! You reading this. Yes, you. Give your best wrong answer below.