I worked at my university after graduation for 2 months (as an employee; well funded project). A project that should have had no more than 4 developers had 3x that many. Tool 2.5x as long to finish (I left in the middle). Crippling, dysfunctional politics, lunch meetings with stake holders, useless field trips. I think everyone involved knew what was going on and didn't care.
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.
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.
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.
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 began early April and we had more FT in-house developers than remote resources. The only reason we got remote workers because it was next to impossible to find good developers.
We initially had a terrible experience with remote workers and it didn't work out at all. But we learned from our mistakes and made it work later on. When I left the company, 100% of its development (i.e. maintenance) is done offshore.
The more questions you'll ask your users, the more confusion you will cause. In the book, "Don't Make Me Think", the author makes an excellent point: "When you're creating a site, your job is to get rid of the question marks."
These days, three questions are most common:
1. Visit the Full Site
2. Visit the Mobile Site
3. Download the App
"Hmm... which one should I pick... I'm not sure..."
Besides, it is plain annoying to see this every single time.
Matt,
Thanks for your feedback, much appreciated - I'm surprised at this myself and the article will be updated soon.
From personal experience, some of my friends use their smartphones for all their browsing, even when they are at home. That could be one of the reasons the WiFi stats are so high.
