561–570 of 704 posts
Earlier quoted context omitted.
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.
The tracking pixel was made my scaling the company logo down to a 1x1 image.
Two reasons for this: (1) You haven't inherited anything, the business owns the code, not you as an individual. You and the tech team need to work together to to make sure the code keeps generating revenue, and possibly more. No one is owning other people or teams. (2) The code is generating $20m annual revenue. That's pretty cool and not bad at all!
I'd follow the following steps:
1. Start by defining responsibility areas: input, code, output (business value). Any codebase can be modelled in this way. Once you have explicitly defined input and output of your code base, you know what your degrees of freedom are as long as you don't mess with input or output of your application. Also a good way to get to know the stakeholder landscape.
2. Introduce version control, move everything to Git. Git enables a nice way-of-working that is recognized industry-wide. Team work is everything.
3. Start writing tests. Preferably E2E tests that will be stable for a long time to come. In all cases, don't disturb the revenue flow with your changes. This will help you to make changes without having angry coworkers in your mailbox when your change caused existing functionality to break.
4. Fix the low-hanging fruit first. Define a list of maximum 5 issues that can easily be fixed in isolation and will improve the code base. Be sure everyone understands why and how things are done. This will boost team ownership.
5. Improve the codebase step-by-step. Be sure for every improvement to explain why it is important in terms of business value. If you can't explain it to yourself, maybe you are just fixing this for esthetics and it's not really important at all.
And finally, don't go for a full rewrite. Rewrites always seem easy, until you remember that you forgot to take into account all the edge cases the original code base did take into account and it's not as simple as you've thought after all. Instead move parts of the code to a new codebase and migrate slowly from v1 to v2.
Earlier quoted context omitted.
> a challenge to secretly improve a codebase without anybody noticing That is how it should be done in any case anyway. Improvements should get slowly rolled out without disturbing the users and the business.
> That is how it should be done in any case anyway. Not exactly. IT management should be always telling people stuff like "did you notice that the integration with XYZ that never worked well stopped failing?" or "did you notice that we delivered those few last features at record time?" and explaining why.
Earlier quoted context omitted.
> OP does not have the corporate experience to handle this situation Even before that, s/he doesn't even seem to understand any measure of business. $20m/year with 3 people is BIG. Any disturbance to whatever makes that happen will hurt the business greatly. When a full rewrite shakes the boat and causes a few millions of revenue loss or the loss of potential market share or opportunities, they will rightly fire him.…
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.
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 amount. You can improve upon whetever margin or inefficiency in the process and increase the net profit - optimize vendors, costs, sales pipeline.
The difficulty in modern Internet business is getting to some place at which you can command $20 m revenue from any market. Finding the customers and the users. Not the margins.
“Before you heal someone, ask him if he's willing to give up the things that make him sick.” ― Hippocrates You have to have a conversation with the people responsible for this shit, including (and specially) stakeholders, make them aware of the problem, and get them on board with respect to the possible solution. This step is essential before even bothering to do fucking anything. Most importantly, make it clear that…
There are some strong arguments here
Earlier quoted context omitted.
In my opinion OP should seriously consider this advice. I really mean nothing patronizing here, but I suspect OP does not have the corporate experience to handle this situation. This is a corporate equivalent of a double-black diamond downhill route. OP was hired by people who have little understanding of tech and already came in with guns blazing. I might almost wonder if OP's a sacrificial lamb. But, the tech advic…
> I suspect OP does not have the corporate experience to handle this situation. I agree with this. OP doesn't say, but reading between the lines, corporate at best doesn't understand the ramifications, but corporate doesn't care about the ramifications. They're getting 20 million in revenue from 3 cheap devs. Things are going great, according to corporate. They're not going to learn, and OP is going to get blamed whe…
Could you define this phrase and what English dialect it's from?
Earlier quoted context omitted.
I agree it's the sane answer. But I don't think these engineers are incompetent. They lacked direction, accidentally followed worst practices, and _still_ came out on top. I would say they are good engineers but perhaps bad project managers / architects.
Not a developer, but I was onvolved, and are again involved, in some crucial dev projects on which the future success of my employer depends. Any developer who deploys to production without testing, or worse, develops directly in production is by every definition at least incompetent. If not an incompetent wannabe rockstar ninja cowboy without even realizing it. And those devs are dangerous .
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 would try to identify how entangled some of the dependencies are and start my rewrite with the goal of getting rid of them. But yeah I agree that version control and testing is going to be key here as you any backsliding will probably result in the idea of future refactoring being viewed negatively.
Earlier quoted context omitted.
I mean like “we want to replace X with Y”. Y incrementally starts replacing X, but 100% migration is never achieved, meaning double the API surface area exists indefinitely. Because the migration doesn’t block new features, that means the org gets tired and reallocates the effort elsewhere before it’s ever done, with no immediate consequences. Rinse and repeat.
I think you've not witnessed Ship of Theseus, but "build Ship2 next to Ship1 and start using Ship2 while Ship1 is still being used and keep saying you're going to migrate to Ship2 eventually but meanwhile Ship1 and Ship2 diverge and now you have 2 ships". I recently witnessed this mess and it is an enormous mess. Don't build Ship2 in the first place. Instead, replace Ship1's mast and sails, and rudder etc until you'v…
Sounds like someone needs to push back against management first and foremost. Without this understanding the only thing you'll succeed in doing is denting that $20m revenue stream with very little appreciable benefit and the higher-ups will understand even less what you're up against.
Get that message right first and small doors may open to better budget. Then approach as others have said, piece by piece, or as Martin Fowler describes as a StranglerFigApp (https://martinfowler.com/bliki/StranglerFigApplication.html)