6 ms·

To me the biggest issue with re-writes is it tends to be Engineering working in a vacuum without business input. What that tends leads to is “blind” 1-to-1 reim

by harryf 8y ago

To me the biggest issue with re-writes is it tends to be Engineering working in a vacuum without business input. What that tends leads to is “blind” 1-to-1 reimplementation of features without reflection on which features are _still_ bringing business value e.g. if most of your user base transitioned to mobile, is it really worth reimplementing all things that were built with users IE on Windows in mind? Or put another way, the place where you can save a ton of effort in a rewrite and increase your chances of success is in throwing stuff away, but you usually need more than just the engineering team to achieve that.

mmsimanga 8y ago
I once worked for a company where we as IT decided that there would be no rewrites without new features. It was basically impossible to get funding for rewrites that would not yield new features for the business. I felt this was the best for both business and IT.
- y4mi 8y ago
  One of my employers once had a queue for pretty much every asynchronous action that had to be done in the platform The workloads were categorized by type and that script decided on the order by base-ing a timestamp and using the resulting integer as an if for each category. This mostly worked,too. Sometimes, if previous workloads took too long, the following category would not be triggered for several cycles... But most of the time, everything was done in a somewhat timeley manner. That is a rewrite that needed to be done, and yet would never be doable with your strategy. There is no new business feature to add, but it still needs to be fixed because as each workload increased, the implemented feature got less stable.
  - lazyasciiart 8y ago
    "Faster and more reliable" is a business feature.
  - ebiester 8y ago
    That just means that any new feature has that work attached to it - “the business cannot add anything more to the queue without this rewrite.”
  - jyounker 8y ago
    What was the cost to the business when it wasn't timely?
- gav 8y ago
  I've had a lot of success with rewrites where the outcome is a lot less functionality, but with one or two new features that have a huge amount of value. For example, rewriting a crufty ordering system that drops 50% of the edge-cases that have accumulated over 30 years, but making it work on mobile devices.
nicoburns 8y ago
Yep, this is where I've had a lot of success with rewrites: where a lot of the accumulated features in the existing system are no longer required by the business, and you can make a much simpler system to serve the remaining use cases
Pamar 8y ago
Oddly enough, my experience is that when IT asks Business "can we finally drop support for feature X? We are pretty sure that Roman Numerals are not used anymore for budget reports..." the answer is "I am not sure, maybe it will become useful again in a year or two. Let it alone".
- slededit 8y ago
  You haven’t communicated the cost. To the business manager it’s essentially free to leave it in - so why not keep the optionality. If you could estimate “keeping feature X costs $200,000 per year in added development time” it would be an easy decision. Through this process of cost estimating you may find that while annoying it only costs $10,000. Any ill will generated from removing it would cost more than that so it should be left alone.
  - Pamar 8y ago
    This has never worked. The project has a maintenance budget that covers everything (bug fixing, new features, migration to new versions of OS, DB etc.). Business requires a certain number of enhancements, the development team is already understaffed and therefore they are often missing the required number of enhancements in a specific release cycle. So the full discussion goes something like this: "Can we remove support for Roman Numerals? We are pretty sure nobody uses these anymore, and we estimate that this would cost 20 man/days in this release but result in a saving of 800 man days over the fiscal year..." "Not sure, it could be useful again, use these 20 days to add support for Aztec calendar to the Insurance reports - you have already postponed this twice!" (I.e. they get the impression that somehow there are 20 "extra" days available and those have to be diverted to implements something that may have become already obsolete).
    - slededit 8y ago
      Never lead a sales pitch with the price tag, always with the benefit. The conversation shouldn’t be about it costing 20 days to remove something. It should be about the net savings from doing so. “Removing rarely used feature XYZ will open up 780 man-days of schedule time this year for new features by improving our efficiency”
52-6F-62 8y ago
> it tends to be Engineering working in a vacuum without business input. Anecdotally, I’ve had precisely the opposite experience at times. Though I can tend toward what you described as a fault, I’ve also experienced abject need to rewrite internally and externally produced software to fulfill business requirements.
- user5994461 8y ago
  I see that happen a lot too. Some businesses decide that they want a new thing and find some developers to work on it. Neither seem to care about existing systems, or integrations. It will be one more legacy soon, if it ever gets anywhere.

by harryf 8y ago

mmsimanga 8y ago

I once worked for a company where we as IT decided that there would be no rewrites without new features. It was basically impossible to get funding for rewrites that would not yield new features for the business. I felt this was the best for both business and IT.

y4mi 8y ago
One of my employers once had a queue for pretty much every asynchronous action that had to be done in the platform The workloads were categorized by type and that script decided on the order by base-ing a timestamp and using the resulting integer as an if for each category. This mostly worked,too. Sometimes, if previous workloads took too long, the following category would not be triggered for several cycles... But most of the time, everything was done in a somewhat timeley manner. That is a rewrite that needed to be done, and yet would never be doable with your strategy. There is no new business feature to add, but it still needs to be fixed because as each workload increased, the implemented feature got less stable.
- lazyasciiart 8y ago
  "Faster and more reliable" is a business feature.
- ebiester 8y ago
  That just means that any new feature has that work attached to it - “the business cannot add anything more to the queue without this rewrite.”
- jyounker 8y ago
  What was the cost to the business when it wasn't timely?
gav 8y ago
I've had a lot of success with rewrites where the outcome is a lot less functionality, but with one or two new features that have a huge amount of value. For example, rewriting a crufty ordering system that drops 50% of the edge-cases that have accumulated over 30 years, but making it work on mobile devices.

nicoburns 8y ago

Yep, this is where I've had a lot of success with rewrites: where a lot of the accumulated features in the existing system are no longer required by the business, and you can make a much simpler system to serve the remaining use cases

Pamar 8y ago

Oddly enough, my experience is that when IT asks Business "can we finally drop support for feature X? We are pretty sure that Roman Numerals are not used anymore for budget reports..." the answer is "I am not sure, maybe it will become useful again in a year or two. Let it alone".

slededit 8y ago
You haven’t communicated the cost. To the business manager it’s essentially free to leave it in - so why not keep the optionality. If you could estimate “keeping feature X costs $200,000 per year in added development time” it would be an easy decision. Through this process of cost estimating you may find that while annoying it only costs $10,000. Any ill will generated from removing it would cost more than that so it should be left alone.
- Pamar 8y ago
  This has never worked. The project has a maintenance budget that covers everything (bug fixing, new features, migration to new versions of OS, DB etc.). Business requires a certain number of enhancements, the development team is already understaffed and therefore they are often missing the required number of enhancements in a specific release cycle. So the full discussion goes something like this: "Can we remove support for Roman Numerals? We are pretty sure nobody uses these anymore, and we estimate that this would cost 20 man/days in this release but result in a saving of 800 man days over the fiscal year..." "Not sure, it could be useful again, use these 20 days to add support for Aztec calendar to the Insurance reports - you have already postponed this twice!" (I.e. they get the impression that somehow there are 20 "extra" days available and those have to be diverted to implements something that may have become already obsolete).
  - slededit 8y ago
    Never lead a sales pitch with the price tag, always with the benefit. The conversation shouldn’t be about it costing 20 days to remove something. It should be about the net savings from doing so. “Removing rarely used feature XYZ will open up 780 man-days of schedule time this year for new features by improving our efficiency”

52-6F-62 8y ago

> it tends to be Engineering working in a vacuum without business input. Anecdotally, I’ve had precisely the opposite experience at times. Though I can tend toward what you described as a fault, I’ve also experienced abject need to rewrite internally and externally produced software to fulfill business requirements.

user5994461 8y ago
I see that happen a lot too. Some businesses decide that they want a new thing and find some developers to work on it. Neither seem to care about existing systems, or integrations. It will be one more legacy soon, if it ever gets anywhere.