perseus323's comments

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.

Sure. But a picture is worth a thousand words. Visual explanations are cool.

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.

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.

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.

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.

Here's a link to the SO question: http://stackoverflow.com/questions/20734835/scalable-nodejs-...

Any comments? or thoughts?