11–20 of 346 posts
And if you have the option to rewrite it and you think you can do a good job, go for it and good luck!
This is easier to deal with both in terms of selling it to management and making sure you don't actually break the whole system compared to a full scale rewrite. I've made that mistake before and it wasn't fun. As others have said, code that's in production and works and is making money has value. The "cleanness of the code" is not something business owners care about, unless it causes problems.
I got it a while back when working on a similar sounding codebase and it was very useful. It's got chapter headings like "My Application Has No Structure" and "I'm Changing the Same Code All Over the Place".
If your company has a books budget get them to buy it, but I'd personally drop the £35 it costs on amazon given how useful this has been to me over the years.
Back in the 90's and early 2000's, almost nothing had automated tests. Miraculously, things still got done by manually testing.
On the other hand, I worked at shops where every getter and setter had a test. Not much got done there.
Are you working at my company? Ok, more seriously: that’s the way existing code is about 90% of the time - it’s the reality of working in our field. It may or may not reflect on the original developer. Maybe they were learning a new framework. Maybe they were rushed. Maybe it was originally intended as a prototype but ended up in production. Maybe the requirements have grown or changed significantly since it was impl…
This. If there are deficiencies in the code base, focus on those, their effects, and the gains from fixing them. Blaming people is rarely a good idea, for many reasons.
If the original dev worked on the code base for a long time, they're probably already aware of them. God knows I'm all too aware of the deficiencies in code I wrote years ago, but that's frequently how things look after years of updates and feature creep. Everyone on our team has code like that, and when new guys come in and point them out, we just sigh and say "yeah it would be great to rewrite that knowing what we know today". But budgeting time for that is not easy.
Edit: Also, like others said, I think you need to adjust your expectations. Working with code like that is life, and you should appreciate the fact that you, with your outside perspective and youthful energy can make a change for the better. But it's going to involve lots of refactoring and test writing.
The "Legacy Code" book referenced in another post is a great overview of this. I'd say of all programming books I've read, it's one of the ones that are most relevant to my day to day work.
There's a book called "Working Effectively with Legacy Code" by Michael C. Feathers which I heartily recommend. I got it a while back when working on a similar sounding codebase and it was very useful. It's got chapter headings like "My Application Has No Structure" and "I'm Changing the Same Code All Over the Place". If your company has a books budget get them to buy it, but I'd personally drop the £35 it costs on a…
Yah i went to a big name host and found the same thing. I was fooled into joining because I met with a data scientist and an "experienced web developer" without actually looking at their code. Long story short, 2 years later it was the most frustrating experience ever and I left, hating the code the entire time. I was paid a lot and the people were cool so that made me hang around but the culture promoted hanging on…
Is it typical to be able to look at a company's code before signing up? After having a similar experience, I wish I could make that a standard part of my interviewing process. (Brief backstory: I would never in 1000 years have taken my first development job if I had seen the code first, but HR and the carefully selected engineers who could tell positive stories gave me a false impression of what was going on.)