Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
Never, ever, I can’t stress this enough, talk bad about the code you have to work on.
As you said, everybody has been on both sides. The client might still like the old dev.
What do you get if you tell them the old code sucks which worked for years? Not the job, in many cases.
Tell them you need to refactor it because newer versions, new requirements, new framework, what ever.
Be diplomatic and everybody is happy ;) -
@ExGetMessage We had a few cases where the client came to us with a prototype and asked to implement features. It is clearly a prototype, the code is scattered.
We've suggested to him that we can finalize the product, find and optimize some parts and fix issues that he is having. He was keen on knowing what we think about the actual code and not the actions so we just said - it's good for what was needed at that time BUT in order to grow - some rewriting would be suggested.
In the end, we received that project and carrying with it for the last few years with no issue. Even the old dev came to meet us and he was happy that the code grew. His main point was that he was just trying to prove the idea and not make a product immediately. Why should the client spend years on an idea which is not any good? (looking at you google :D ) -
@hack The best part is that you get the job done. Hate the code all you want but if it was working for previous cases - it did the job
-
@potata My solution is to give the prototype a lifecycle.
In the UI - marked in the About section - "this is a prototype that will expire at..."
Also in the code comments. Client can decide if they want to use it, or invest a bit more, and fix yhe mess. -
@magicMirror Great idea to be fair! Never thought about it.
We are all about structures, clean code and many other things that make our life easier, right?
Well... It's not all white and black...
As talked many times, projects can be rushed... Client budgets can be low at the start and only then grow...
Let me take an example:
Client X needs a tool that helps his team perform jobs faster. They have a $500 budget. So... Testing, clean architecture and so on - are not really a viable option. Instead, you just make it work and perform that task as needed. So the code has minimal patterns, minimal code structure, a lot of repetitive parts and so on.
Now... Imagine that 3 months pass by without any notice and clients are ultra happy with the product. They want more things to be automated. They contact developers and ask for more things. This time they have a bigger budget but short timeframe.
So once again, you ignore all tests, structure and just make it work. No matter what. The client is happy again.
A year passes and the client realizes that their workflow changed. The app needs total refactoring. The previous developer has no time for adjustments at this point and hires a new company. They look at the code and rants spill out of their mouth along with suicidal thoughts.
So... What would you do? Would you rant about "messy project" or just fix it? Especially since people now have a bigger budget and timeframe to adapt to changes.
Would you be pissed on such a project?
Would you flame on previous devs?
Would you blame anyone for the mess?
Or would you simply get in and get the job done since the client has a "prototype" and needs a better version of it?
---
Personally, I've been in this situation A LOT. And I'm both, the old and new dev. I've built tons of crappy software to make things work for clients and after years - they come back for changes/new things. You just swallow the pill and do what is needed. Why? Well, because it's an internal system and not used by anyone outside their office. Even if it's used outside the office - prototyping is the key. They didn't know if the idea would work or be helpful in any way. Now they know and want it done correctly.
rant