Hacker News Reader

Comment by copperx | Hacker News Reader

Wasn't the rewrite was a technical success despite warning signs?

The customer simply didn't want to adopt the shiny new software.

The rewrite was a technical success. But we missed real business opportunities and completely underestimated the effort of building a new system while maintaining the legacy one in parallel. In short, we didn't prioritize and miscalculated big time :-)

The customer confidence in us had eroded because we weren't responding to their new feature requests in the legacy system. Plus their management didn't want to take any risks since the new system offered to new features to them and only benefited us.

What about responding to their feature requests... in the new system? !

Then they'd have the motivation to make the switch.

That's the problem. From my reading of the article, their client was, probably legitimately, concerned with the risk of a cutover to a new and unproven system.

To implement a new system the client always needs to do UAT. That's actually a drain on their resources, and if they have a working system it is far better to have incremental changes made and a regular set if bug fixes than to launch a new system, then find a raft of new bugs or unexpected changes that need to be fixed anyway.

Existing systems allow enterprises to operate effectively. New systems almost always cause unexpected disruption to a business regardless of efficiencies gained from the new system. And most IT systems are to support the objectives if the business, they aren't the actual objective if the business. A software development company can lose sight of this because it IS the objective of their business :-)

Good point. The UAT was definitely one of the reasons. It was several Excel spreadsheets long and scheduling it was a pain :-)

Also, it was a hosted service and client saw no value to them- just the pain. There was risk of service outage during the upgrade that would have had resulted in the loss of revenue. Also, the client had to provision extra resources to run Cassandra/SOA servers. In short, it was a lot of work for them with no benefit to them.

We tried that and that's how we eventually got them to switch - 2 years later. The client required a feature to start 'live sessions' with mobile subscribers whenever they were active on the network (made or received a call) and support for multi-level menus. The original architecture was transactional and they understood its limitations. The rewrite used SEDA and we were having latency issues, gc and memory issues handling live sessions with SEDA. So we had to do another upgrade to switch from SEDA to Actor based model that worked. The next upgrade was small and incremental compared to the first one very and we had the system ready by the time contract was finalized.

Could you have made major changes to subsystems in the original system and then gradually worked towards a total rewrite incrementally?

You would have had to work very carefully and have an extremely solid test framework and methodology but I'm wondering if it might not have allowed for adding the features the client wanted and prevented a situation where you had to do a major cutover on code that wasn't tested in the field.

There is no way to know if it was a technical success since it was never used by real customers. It might be full of bugs and bad decisions. In fact, by default unused code should be assumed to be full of bugs and problems.

That's the reason behind the success of continuous integration and deployment. At least bad code stay hidden for a very short time and needs to be fixed before other things can be built on top of it.

"The operation was a success, but the patient died"

Reply on news.ycombinator.com