51–60 of 346 posts
Earlier quoted context omitted.
Only successful applications have the pleasure of getting old.
"Successful" by literally any measure.
If the environment itself is good, and you like the people you work with, then you should see it for the great opportunity that it is; learn how to slowly evolve a large software project for the better. There's none of the stress of trying to figure out the "right" architecture, no worrying about making bad decisions. You can just chip away tidying things up.
Things that are probably a bad idea: Trying to rewrite (will almost certainly fail), Blaming others (it's no one's fault, it just is what it is), Walking away (negative signal for future employers).
> I've already made some comments about rewriting it and the response was basically "ok". Do it. Gradually. Rename. Simplify. Reduce. Enhance. Test. Slice and dice. Embrace the shitiness. Accept it. Own it. It's your playground. Sharpen your skills, and lead them to the promised land. It could be worse. You could face major resistance and people issues. Appreciate it. This is an opportunity for you to kick a billion…
Also see if you can make a to-do list. This will help make your request concrete to management. As you cross items off it will help them see that you're actually getting work done. And, it could help to motivate you if you feel like you're "just rewriting the code".
But from your post it sounds like your immediate problem is you don't like working on ugly code. Thrn I'd suggest trying to get transferred, rewriting jto from scratch (at most companies this would be a hard sell, and probably a money pit), or find a new job.
Complaining about the code is only going to make your workplace more hostile.
If you do decide to go for the rewrite option try to make the case from a financial aspect. Calculate the cost of maintenance, the cost of the rewrite etc...
Look into various books and articles on refactoring. Don't change things open-loop, write tests if you can, manually run and verify too.
No. This has the disadvantage of possibly making you look naive. The code might actually be fine and you might not have enough experience working in unfamiliar codebases or reading other people's code. Moreover, original developers will have made choices for a particular reason, often without commenting and you might change something unintentionally if it doesn't read straightforward the first time through.
If it's mostly style issues, forget it. Unless it's highly trafficked code, the computer doesn't care if you use PascalCase or snake_case or awkward indentation, etc.
Report that you might be wrong, but the code seems overly verbose/incorrect/hard-to-read in some areas and that you are carefully refactoring, but that you are still getting familiar with the company's product and would be excited to work on a different area of the codebase as soon as this project is complete.
Is it buggy? Is it insecure? Is it slow? If the answers to those questions are no. Then you the problem and you should look for employment elsewhere. You are unhappy in that job, and you rewriting the codebase would potentially make the above questions answer to a YES, inflicting damages in the company. Now, if the above questions have yes as an answer. Talk to your manager, explain how it won't scale, how it is hack…
I like to think I'm pretty good at programming, development, and generally architecting solutions. I don't have a lot of experience, but I have a bit of talent and spent a lot of free time learning. Solving problems with computers is something I'm passionate about.
I started this particular project without any idea of what it was (okay, they told me what it was, but it turned out to be something completely different). When we did a kickoff it was myself, two other developers (who both said during the kickoff they didn't want to be on this team, and wanted to go back to admin'ing MSSQL databases), and a non-technical TPM (last time he touched a terminal was a decade ago, and he wasn't particularly interested even back then).
I ended up doing pretty much all the work. My PM would CC me on emails, I'd write the stories, he'd help prioritize them, and I'd do them. The first few weeks they wanted three services stood up and managed in an automated fashion. I got it done, it wasn't pretty. Hell I hadn't even figured out a DNS scheme, but this had to get done so other teams would be unblocked; it was the development account so I wasn't too worried about rushed work.
Then we got more requests from other teams, and vague requirements from the infosec and governance teams. Then the board that reviews new technologies shot down our (my) requests to introduce automation services like Ansible Tower. Then the AWS team shot down our request for multiple accounts, one per environment.
At this point the Cloudformation isn't scaling, I beg and plead for some time to freeze feature development and move to Terraform. I asked for 3-4 weeks, and was given 4 days. This was the one chance to move to Terraform though, otherwise we'd be using Cloudformation for the foreseeable future. So I took it, deciding I could rush through the Terraform rewrite, because then at least we could refactor it later during downtime.
Next thing you know a year has gone by and we're going into production. Everything on the devops end goes pretty smoothly. My velocity is crap though, due in large part because of the shitty rushed work, which it seemed was all I was capable of.
A few months after go-live, we finally get a real TPM, which was a godsend. I was moving to another team at this point, and so his first order of business was to replace me with two new guys. I spent a lot of nights interviewing and a month afterwards helping them get up to speed. I and the new TPM gave them cover that month so they could embark on rewriting the Terraform.
They ignored my suggestions on how to refactor it, which is okay, I was leaving the team, it was their code as now. But it was hard, hearing them laugh at the code behind my back, saying how bad it was. Never giving me a chance to justify it, or even reading the commit messages, to understand why it was done that way.
I'm off the team now, and while I recognize I left a lot of legacy code behind (which I'm not proud of), it wasn't just me who created it. It was also the business who said time and again development speed was the most important thing.
That's how one legacy codebase was created. There were a lot of things I might have been able to do differently (mostly politically), but I truly believe I did the best I could with what I had. But what do I know? My new TPM seemed to agree with me, but maybe he just didn't want to make an enemy. Perhaps I could have headed it off if I'd said the right words to the right people. I don't know, will never know.
This experience is why I don't make fun of others solutions. Somebody put effort and time and thought into it, and I guarantee (in most cases) I don't have that context to properly evaluate it.
1. Stop "repairing" it because you're guaranteed to introduce bugs and regressions. You haven't learned it well enough and can already sense the fragility, which is why you're anxious. 2. Relate your impressions to the person in charge: "The code doesn't seem to follow best practice and appears fragile. You think there may be technical debt that needs to be addressed sooner than later." 3. Until you're confident enou…