4 ms·
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
by 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 agoOne 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 agoThat 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 agoWhat was the cost to the business when it wasn't timely?
- gav 8y agoI'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.