681–690 of 704 posts
Start building a wiki and get knowledge from your team - they built everything in the first place. Embrace what they know and go from there.
Have you heard of Swimm for knowledge base/wikis/documentation?
However the lack of budget and that the management has an 'aggressive roadmap' says that the management team is toxic, ill-informed, negligent, and ignorant.
Your mental heath takes priority. Get the fuck away from that tyrefire of a company
Earlier quoted context omitted.
I fully agree with this, but I think it misses a key step: As the team’s manager, it’s your job to get buy-in from the executives to gradually fix the mess. You don’t need to tell the team exactly how to fix it, but you gotta get buy-in for space to fix it. One approach is just to say “every Friday goes to adding tests!” (And then when there’s some reasonable test coverage, make fridays go to refactoring that are eas…
Before anything else, getting buy-in for any kind of major change from the execs is key. Explain the situation and the effects. Have everything in writing, complete with date and signatures. Push back hard every time this commitment gets sabotaged because something is supposedly on fire. Get a guaranteed budget for external trainings and workshops, again in writing. Then talk to the team. If you cannot get those comm…
Earlier quoted context omitted.
You have a great experience and did a great job indeed. My only question is how does one get 20 years of such experience without horrific flashbacks of “let’s just rewrite it” decisions. Do you do rewrites/redesigns often? What’s your success rate?
I've done what I would consider as four rewrites that I can remember as large events in my life (although not fully what you'd expect). But all are good stories in my opinion. First one was the above example. It was for the largest hardcore porn company on the planet. Myself and my good friend Jeff rebuilt an already successful business IT department from the ground up and made it even more successful. Ever heard of…
Set up two nginx servers. One that's your usual to load Laravel and the other to the legacy nginx server that acts as routing to the legacy application. I would even recommend using OpenResty to help delegate if you need something intelligent.
I would strongly discourage a JS framework that would add increased complexity when you need to keep things focused. The front-end would need to be recorded in Laravel and brought back over in a clean fashion.
Set up a CI and ensure all the code that goes over to Laravel is near 100% tested. Might also be useful to set up a visual regression test tool such as Percy to ensure everything moves over nice. Push for SMACCS and BEM to keep things consistent. Or just make new styling for the new pages to surprise the users.
Rewrites are a trap though and can be painful. Keep a balance of features entering Laravel and the big foxes entering the legacy app. I would recommend RabbitMQ to communicate between them.
Earlier quoted context omitted.
Is the entirety of the whole company just 3 people? It doesn't sound like it. That 3 person team is just 'tech' it seems - there may be 5-10 managers/sales/support/etc people. And... $20m is revenue, not profit. If the cost of their sales is, say, $15m... and there's 15 people working at the company, that's quite healthy, but it's not some money-printing goldmine at this stage.
> Is the entirety of the whole company just 3 people? From what is told in the summary, it seems like the software stack and these 3 people constitute the core of the business that is going on. The business may be something totally different. But it seems to be running on that software. > And... $20m is revenue Even if they have lower margins than what you yourself imagined, $20 m revenue/year is still a gigantic amo…
It’s not difficult getting to a high revenue fueled by aggressive and expensive acquisition using money from investors who gets dazzled by growth numbers, but if your customer lifetime value is low and you’re not a pure SAAS business which means margins won’t automatically improve with scale, turning that company profitable can prove very difficult.
Earlier quoted context omitted.
This is more reason for the gradual approach. Bringing source control, testing, and separation of dev and prod environments, makes things safer and will speed up work pretty soon by making the people much more comfortable to actually try things.
For what benefit in the end for the individual?
Once you have these things in place, you can make changes much more quickly, and much more confidently.