4 ms·

There are those who forge the path and those who finish the paving. Both types are required as it's exceptionally rare to find people who can consistently do bo

There are those who forge the path and those who finish the paving. Both types are required as it's exceptionally rare to find people who can consistently do both.

t0mbstone 5y ago
I can do both (and have), but it really is a case of time constraints. So I let management decide. Do they want a quick prototype that is going to be unstable and buggy and difficult to maintain long-term, or do they want something solid that is well tested and stable and refactored and well-documented so newcomers can work on it easily as the team grows? There are trade-offs. The quick prototype allows you to get something in front of your stakeholders that resembles the desired end product. This allows them to easily identify things that they missed, and allows them to quickly change direction if need be. This can backfire really easily though, because if your prototype is too good, they will think it's a polished product that can be sold even though it's completely lacking tests and is duct taped together behind the scenes. You have to CONSTANTLY remind them that THIS IS NOT A STABLE PRODUCT and that it still needs tests and refactoring and clean-up. A lot of the time, you will have to create the JIRA stories and advocate for this extra work to be done yourself, or else management simply won't prioritize it. I've been a part of multiple startups with successful exits now, and they were all based on code that was rapidly prototyped and duct taped together behind the scenes. Being able to pivot and adapt is more important than stability, when you are a startup. But once the startup has been bought by a larger company, it's probably time to rewrite and refactor and stabilize things. Now that you have big clients and people depending on the systems, it's time to batten down the hatches and prioritize stability and longevity.
- w0m 5y ago
  > So I let management decide. Do they want a quick prototype that is going to be unstable and buggy and difficult to maintain long-term, or do they want something solid that is well tested and stable and refactored and well-documented so newcomers can work on it easily as the team grows? In my experience; every time I've shown a quick prototype that 'mostly' worked - that went into production.
  - t0mbstone 5y ago
    Yep. That's why you have to give management the full disclaimer and sign-off so they are aware of the risks of launching a prototype as if it was production ready. The decision and ramifications of their decision should be on them, not the devs.
    - w0m 5y ago
      Re: Ramifications - management tends to be fine with asking me to prop up a POC-as-production service for years after the fact with duck tape and bubblegum.

There are those who forge the path and those who finish the paving. Both types are required as it's exceptionally rare to find people who can consistently do both.

t0mbstone 5y ago

I can do both (and have), but it really is a case of time constraints. So I let management decide. Do they want a quick prototype that is going to be unstable and buggy and difficult to maintain long-term, or do they want something solid that is well tested and stable and refactored and well-documented so newcomers can work on it easily as the team grows? There are trade-offs. The quick prototype allows you to get something in front of your stakeholders that resembles the desired end product. This allows them to easily identify things that they missed, and allows them to quickly change direction if need be. This can backfire really easily though, because if your prototype is too good, they will think it's a polished product that can be sold even though it's completely lacking tests and is duct taped together behind the scenes. You have to CONSTANTLY remind them that THIS IS NOT A STABLE PRODUCT and that it still needs tests and refactoring and clean-up. A lot of the time, you will have to create the JIRA stories and advocate for this extra work to be done yourself, or else management simply won't prioritize it. I've been a part of multiple startups with successful exits now, and they were all based on code that was rapidly prototyped and duct taped together behind the scenes. Being able to pivot and adapt is more important than stability, when you are a startup. But once the startup has been bought by a larger company, it's probably time to rewrite and refactor and stabilize things. Now that you have big clients and people depending on the systems, it's time to batten down the hatches and prioritize stability and longevity.

w0m 5y ago
> So I let management decide. Do they want a quick prototype that is going to be unstable and buggy and difficult to maintain long-term, or do they want something solid that is well tested and stable and refactored and well-documented so newcomers can work on it easily as the team grows? In my experience; every time I've shown a quick prototype that 'mostly' worked - that went into production.
- t0mbstone 5y ago
  Yep. That's why you have to give management the full disclaimer and sign-off so they are aware of the risks of launching a prototype as if it was production ready. The decision and ramifications of their decision should be on them, not the devs.
  - w0m 5y ago
    Re: Ramifications - management tends to be fine with asking me to prop up a POC-as-production service for years after the fact with duck tape and bubblegum.