4 ms·

You have the right insight I think. The thing about putting lots of effort into "refactoring" is that the code you refactor may actually not end up in the produ

You have the right insight I think. The thing about putting lots of effort into "refactoring" is that the code you refactor may actually not end up in the product at all. I think "prototyping" is better than "refactoring". Prototyping basically means that you write your app more than once. On the 2nd round you know what needs to be there and what not. You may have come up with a much better much simpler design for the whole system when you know what needs to be there and what it needs to do. Code-quality is important no doubt, but it is not important for code that doesn't end up in the final product.

mecha_ghidorah 4y ago
I definitely think prototyping should be more common but the problem is I've been burned before. "Just build a version of this thing as quickly as you can. Don't worry about performance or anything so much, the goal is to get an idea of what these features might actually feel like to use so this is just a proof-of-concept project" Then "Oh hey we are going to give that proof-of-concept project to a client to try out and give us feed back. Don't worry they know it's just demo code at this point".... Shortly after that though it's "The client wants these changes and you're who has to support it now. The client says it's slow, why is it slow? Client wants a new feature, add a new feature!" And I'm left dealing with a horrid, awful, garbage piece of code because I'm the one that wrote it. I was explicitly told to write it entirely as a proof of concept and not as anything production ready which is why it's shit. This has happened to me more than once. So until I have my PMs and Team lead tell me a thing is going to be a prototype/PoC and it turns out to actually be one at least once at this point I assume it's a lie
- NateEag 4y ago
  The key to having prototypes and PoCs work out okay is to leave some important piece of UX out entirely. Such an approach gets you the benefits of being able to explore a problem space with code in a quick, sloppy manner, without any risk of anyone actually deploying what you wrote.
  - eurasiantiger 4y ago
    Never make prototypes easy on the eyes. Use Comic Sans liberally. That way nobody will assume it is the final application which just needs a few touches.
  - galaxyLogic 4y ago
    That's a great idea. Prototype must look like a prototype
    - NateEag 4y ago
      Not even just "look like a prototype" - a prototype must be _incomplete_. If it's not? You have a solution, so of course it's going to be deployed. The fact that your solution is gonna fall over due to being brittle code is really unfortunate, but it was avoidable if you'd just built a prototype instead of a product.
      - mecha_ghidorah 4y ago
        I mean that's easier said than done in some cases. If your manager wants you to build a complete version of the functionality, just one that is very "quick and dirty" there isn't a whole lot you can do to make it not fully functional short of flat out refusing
        NateEag 4y ago
        Sure, but as noted that isn't a prototype - it's a sloppy product. That's when it's time to have a frank discussion about whether that's really what they want (and maybe to consider whether this project is really what you want to be working on, if it's a common pattern).
- galaxyLogic 4y ago
  Yes that easily happens
eurasiantiger 4y ago
Refactoring is probably a sign of problems, unless by refactoring one means ”giving abstract structure to yet unstructured code”, i.e. factoring for the first time. That needs to happen after feature-completeness, but before a project goes into maintenance.
- rob74 4y ago
  Well yeah, if the code was without "problems" (using the widest definition of "problems", including stuff like "code smells"), you wouldn't have to refactor it. But such "problems" don't necessarily mean that the code was bad in the beginning, it might also mean that the requirements have changed in a way that the original code structure can only handle using hacks...

mecha_ghidorah 4y ago

I definitely think prototyping should be more common but the problem is I've been burned before. "Just build a version of this thing as quickly as you can. Don't worry about performance or anything so much, the goal is to get an idea of what these features might actually feel like to use so this is just a proof-of-concept project" Then "Oh hey we are going to give that proof-of-concept project to a client to try out and give us feed back. Don't worry they know it's just demo code at this point".... Shortly after that though it's "The client wants these changes and you're who has to support it now. The client says it's slow, why is it slow? Client wants a new feature, add a new feature!" And I'm left dealing with a horrid, awful, garbage piece of code because I'm the one that wrote it. I was explicitly told to write it entirely as a proof of concept and not as anything production ready which is why it's shit. This has happened to me more than once. So until I have my PMs and Team lead tell me a thing is going to be a prototype/PoC and it turns out to actually be one at least once at this point I assume it's a lie

NateEag 4y ago
The key to having prototypes and PoCs work out okay is to leave some important piece of UX out entirely. Such an approach gets you the benefits of being able to explore a problem space with code in a quick, sloppy manner, without any risk of anyone actually deploying what you wrote.
- eurasiantiger 4y ago
  Never make prototypes easy on the eyes. Use Comic Sans liberally. That way nobody will assume it is the final application which just needs a few touches.
- galaxyLogic 4y ago
  That's a great idea. Prototype must look like a prototype
  - NateEag 4y ago
    Not even just "look like a prototype" - a prototype must be _incomplete_. If it's not? You have a solution, so of course it's going to be deployed. The fact that your solution is gonna fall over due to being brittle code is really unfortunate, but it was avoidable if you'd just built a prototype instead of a product.
    - mecha_ghidorah 4y ago
      I mean that's easier said than done in some cases. If your manager wants you to build a complete version of the functionality, just one that is very "quick and dirty" there isn't a whole lot you can do to make it not fully functional short of flat out refusing
      - NateEag 4y ago
        Sure, but as noted that isn't a prototype - it's a sloppy product. That's when it's time to have a frank discussion about whether that's really what they want (and maybe to consider whether this project is really what you want to be working on, if it's a common pattern).
galaxyLogic 4y ago
Yes that easily happens

eurasiantiger 4y ago

Refactoring is probably a sign of problems, unless by refactoring one means ”giving abstract structure to yet unstructured code”, i.e. factoring for the first time. That needs to happen after feature-completeness, but before a project goes into maintenance.

rob74 4y ago
Well yeah, if the code was without "problems" (using the widest definition of "problems", including stuff like "code smells"), you wouldn't have to refactor it. But such "problems" don't necessarily mean that the code was bad in the beginning, it might also mean that the requirements have changed in a way that the original code structure can only handle using hacks...