391–400 of 704 posts
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.
This code is making $20mio, so something must be going well. Don't forget that a codebase like this covers all the history and knowledge.
So first make sure that you appreciate the work of the current team. As you write "resistance to change is huge" I would bet that the team doesn't feel like you're trying to understand them.
It actually reminds me of a client who I wrote an order system in PHP that made $15mio annually. As the client and me didn't get along anymore he was looking for someone to replace me, and found this new CTO who came in with "everything's shitty, nothing works, we need to redo everything". Obviously the client finally saw the chance of getting rid of me, only to ask me one month later to come back as they fired the new CTO. Seems like something was working all along :)
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…
Yes, 3 people creating a revenue of $20 million/year is impressive.
But what if 1, let alone 2 of them quit and/or fall ill? That's way too much risk for this type of revenue.
If a new team member needs a year to just understand how the code is organized, then a well structured and documented rewrite certainly is necessary.
Earlier quoted context omitted.
> It doesn't work. That's simply not true. I've inherited something just as bad as this. We did a full rewrite and it was quite successful and the company went on to triple the revenue. > get some testing in place Writing tests for something that is already not functional, will be a waste of time. How do you fix the things that the test prove are broken? It is better to spend the time figuring out what all the featur…
Of course a full rewrite can be successful. This is the problem when people base their entire critical thinking on blog posts. They then go on to preach it everywhere as well!
The blogs are plainly stating, "even though you feel you should rewrite, you probably shouldn't."
> this code generates more than 20 million dollars a year of revenue From a business perspective, nothing is broken. In fact, they laid a golden goose. > team is 3 people, quite junior. One backend, one front, one iOS/android. Resistance to change is huge. My mistake, they didn't lay a golden goose--they built a money printer. The ROI here is insane. > productivity is abysmal which is understandable. The mess is just…
Some developpers seem to think that their jobs is to engineer nice and beautiful systems. It's not.
As a developper, you're getting paid (fyi the minimum so you don't leave the company) in order to maximise total shareholders' returns. That's it.
The business doesn't care if the codebase is garbage, with massive technical debt, nor if you struggle working with it. That's literally not even a problem as long as it is concerned.
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…
I have tactical suggestions, but the strategy is simple: move toward more modern software practices, one step at a time.
But first, the elephant in the room. You say you need to help the project
> without managing [the team] directly
Who does? How can you help them?
Because you don't have direct authority, all the tactics and suggestions mentioned here won't be as helpful as they would if you were the manager in charge. And it's hard to offer concrete advice without knowing exactly how you are connected. A principal in the same company and want to help? A peer of the manager? A peer of the team members? Each of these would have different approaches.
And how much time do you have to help? Is this something you are doing in the shadows? Part of your job? Your entire job?
With that said, here's my list of what to try to influence the team to implement. Don't worry about best of breed for the tools, just pick what the company uses. If the tool isn't in use at the company, pick something you and the team are familiar with. If there is nothing in that set, pick the industry standard (which I try to supply).
1. version control. Git if you don't have any existing solution. GitHub or GitLab are great places to store your git repos
2. bug tracker. You have to have a place to keep track of issues. GitHub issues is adequate, but there are a ton of options. This would be an awesome place to try to get buy-in from the team about whichever one they like, because the truth it is doesn't matter which particular bug tracker you use, just that you use one.
3. a build tool so you have one click deploys. A SaaS tool like CircleCI, GitHub actions is fine. If you require "on prem", Jenkins is a fine place to start. But you want to be able to deploy quickly.
4. a staging environment. This is a great place to manually test things and debug issues without affecting production. Building this will also give you confidence that you understand how the system is deployed, and can wrap that into the build tool config.
5. testing. As the parent comment mentions, end to end testing can give you so much confidence. It can be easy to get overwhelmed when adding testing to an existing large, crufty codebase. I'd focus on two things: unit testing some of the weird logic; this is a relatively quick win. And setting up at least 1-2 end to end tests through core flows (login, purchase path, etc). In my experience, setting up the first one of each of these is the toughest, then it gets progressively easier. I don't know what the industry standard for unit testing in php is any more, but have used phpunit in the past. Not sure about end to end testing either.
6. Documentation. This might be higher, depending on what your relationship with the team is, but few teams will say no to someone helping out with doc. You can document high level arch, deployment processes, key APIs, interfaces, data stores, and more. Capture this in google docs or a wiki.
7. data migrations. Having some way to automatically roll database changes forward and back is a huge help for moving faster. This looks like a viable PHP option: https://laravel.com/docs/9.x/migrations which might let you also introduce a framework "via the side door". This is last because it is least important and possibly more intrusive.
None of these are about changing the code (except maybe the last one), but they all wrap the code in a blanket of safety. There's the added bonus that it might not trigger sensitivities of the team because you aren't touching "their code". After implementing, the team should be able to move faster and with more confidence.
Since you are not the direct manager, you want to help the team get better through your influence and through small steps. That will build trust and allow you to suggest bigger ones, such as bringing in a framework or building abstraction layers.
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…
My thoughts:
* Get the code in source control straight away
* Get the infrastructure stable and up to date if it's not
* Get CI pipelines set up. As part of this, make sure the code is running through a static analyser. This will give you a backlog of things to work on.
* Organize an external penetration test to be carried out
* Investigate updating and/or consolidating the software libraries used (Jquery etc)
* Choose a page/feature to update on its own. Bring it up to date.
At this point, you should be in a much better state and you will have learned a lot.
Whatever else you do, I hope you and the organization figure out how to celebrate that those three people are generating 20 million dollars of revenue (or at least keeping part of the machinery that does that running.
"I know a full rewrite is necessary, but how to balance it?"
Well, maybe...
How much code is it? How much traffic does it receive?
----
I would be looking at https://martinfowler.com/bliki/BranchByAbstraction.html or https://martinfowler.com/bliki/StranglerFigApplication.html
We also introduced git as well as dev and staging tiers and some agile methodologies. Definitely do some that first!
Now, as management and customers are happy, the backend can be refactored step by step. Here, more test coverage might come in handy.
So, I'd recommend to be a bit picky about where to create value. You can restructure the whole database and that'll be good for maintenance (and most likely performance) but management & customers won't literally "see" much. Ask the people with the money for their preferences, excite them to get more runway. Regarding "backend stuff": Think like a Microservice architect and identify components that are least strongly coupled and have a big (performance) impact. Work on those when management is happy and you've got plenty of budget.
Your job is to create value and reduce risk. Not to create something that's technically awesome ;)