341–350 of 704 posts
Earlier quoted context omitted.
For what benefit in the end for the individual?
I've done that progressively over two years as a junior and I'm basically unofficial tech lead now. Managers listen to me and I can plan and influence several projects. I have other goals so I won't become official team lead by choice, but that's probably valuable to OP if he can pull that off.
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…
We (my good friend and I who both have 20+ years of experience) were brought in specifically do to the rewrite. We were new to the company. We actually had to rebuild the entire IT department while we were at it as well. > new tech team immediately committed to rewriting the code base into ruby micro-services well... sigh. > These refactors inevitably failed to produce a meaningful impact to revenue It sounds like le…
Earlier quoted context omitted.
Yes, life is too short and there are so many much better jobs to waste time on such a project.
Do you work at Google? They never repair things. Hence 5 (10?) unfinished chat programs.
>> I know a full rewrite is necessary
Rewrite it in rust! /s
You’re most likely focussing on the wrong thing here. The tech doesn’t matter. It’s a business, this bit matters:
>> this code generates more than 20 million dollars a year of revenue
You need to be able to quantify which lines of code you’re going to change to increase that 20 number to something higher, or at the very least, increase the amount of that the business gets to keep rather than burn on costs.
This might sound like a hard problem at first glance but it’s really not.
>> This business unit has a pretty aggressive roadmap
This is a positive. To be clear the worst case is an apathetic business unit. This is huge, you’re already ahead. People want things from you so you’re free to exchange what they want for what you need. Think of other business units as part of your workforce, what can they do to help you?
>> management and HQ has no real understanding of these blockers
Yeah that’s the way it is and it’s totally ok, management doesn’t fully appreciate the blockers impacting the HR unit or plant maintenance or purchasing or customer service or etc etc but they DO NEED to know from you the problems you can see that they care about.
That means issues about how code quality are problematic are out of scope but informing management that your team are going to continue to be slow for now are in scope.
Issues about developing in production are out. Issues about your working practice is unsafe and we have a high risk of breaking the revenue stream unexpectedly over the coming weeks and months, that’s in scope for being communicated. At the same time, take them through the high level of your mitigation plan. Use neon lights to point out the levers they can pull for you, e.g. we need SAAS product X at a cost of $$$ for the next year to help us deliver Y $$$ in return.
For every strategic piece of work you line up, be clear on how many $$$ it’s going to unlock.
Be clear on how you personally can fail here. Transparency and doing what you say you will go a long way.
Practice saying no.
You’re an unknown quantity to them so get ahead of that. For example, make it so you’re always first to tell the other units when the product has broken for a customer, rather than customer service telling you about a support ticket that just came in.
Very gradual, well-tested evolutions is the way to go. If it were me I would add a LOT of unit and integration tests before I changed anything. I would also formalize the expected behaviour, schemas, APIs, etc.
You’ve inherited the Ship of Theseus. Believe it or not, this is actually a huge boon for you. 18 months from now your managers will look back and say, “wow this is the same ship?! I want you on my team wherever I end up.”
1. Start adding logging all throughout, wherever changes are being made. That can quickly build up insight into what's happening where and gain confidence into what can be deleted safely. You want the meeting where you can show that an entire file is completely unused and has never once been called for months. It surely exists. Find it. Then say you won't delete it, you'll just comment it out.
2. As you make changes, start doing things twice: one in the way that patches the code as directly as you can manage, the other a stub into a possible design pattern. You don't want to force the pattern into production as soon as you think it works, instead you wait until the code hits a certain evolutionary state where you can "harvest" it easily. Think "architecture as a feature-flag". If it turns out your design can't work, nothing bad happens, you just delete those stubs and give it another go.
3. I would not actually worry about the state of the tooling otherwise. Backups for recovering from the catastrophic, yes. Getting the team on git, not as important. Adding standardized tooling is comforting to you because you're parachuting in. It adds more moving parts for the other devs. That's true even when they benefit from it: if the expected cost of wielding a tool wrongly is high enough to cause immediate danger, you can't proceed down that road - in woodworking that means lost fingers, in software it means lost data. You have to expect to wind down the mess in a low-impact, possibly home-grown way. There are always alternatives in software. And there are likewise always ways of causing fires to fight.
This job most likely isn't going to lead towards using anything new and hot. But if you go in with an attitude of seeing what you can make of the climate as it is, it will teach you things you never knew about maintenance.
Also, the "without managing them directly" is interesting. Are you a peer of the existing three team members?
Get the business to buy into "fixing" this before doing anything. Convince them to hire more, sounds like the current team is already swamped.
If you don't get business buy in, it may be the wrong place for you.
Let me rearrange some of your points: > - it runs on PHP > - it doesn't use composer or any dependency management. It's all require_once. Great --- explicit dependencies are better than magic. Personally, I'm a fan of require rather than require_once, because of some history, but require_once is mostly fine. > - it doesn't use any framework > - no MVC pattern of course, or whatever pattern. No templating library. It'…
(Obviously the real problems are political, but ignoring that...)
Seems to me that after it's in source control and a dev/staging system exists, the next step is to add in a data access layer - move all the raw SQL etc out of the main codebase into either new PHP code or a web service. Then add a bunch of logging so it's possible to discover what parts of the system actually get used. The data layer can then get useful test coverage, allowing the DB to be safely rearranged. The next step is to treat the rest of the PHP app as a black box and write tests around it with something like Selenium, and the work of replacing it with some other boring but more modern technology bit by bit can begin.
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…
Exactly. If they write tests, they will be just doing TDD where the specification becomes a problem in itself.