I thought I must have heard him wrong, because all the business units did agile and, from what I understood, had been for quite some time. It seemed a strange and uninformed question. It did not bode well for the project.
Was it worth the wait?
They finally came back with their new system for us to try out, and I looked into it. I wanted to find the methods for login as well as the process we could use to check our customer's balance. The login was there, along with a couple more parameters than I would have liked. I was told we weren't the only one using this, so I accepted that someone else must need them.
But I couldn't find anything to tell us the available balance. I emailed back and forth with the back-office team asking if all our methods were implemented or if this was just a first draft. I was told that everything we requested was there, so I inquired, "How do I see a user's balance?" The answer was as follows:
- Call the order method, passing in our customer's ID
- Iterate over that list and collect all of the order line-item IDs
- Pass the order line-item IDs to a separate method and get a list of all order line items
- Look through the list of order line items for our product code and sum all credits
- Call the transactions method, passing in our customer's ID
- Iterate over all the transactions for our product code and sum the debits
- Take the difference between the debits and credits -- that was the balance for the customer
They had taken a single query against a SQL Server and turned it into multiple Web requests that returned much more data than was needed.
As we fought this design, we repeatedly came up against a canned refrain: "This is a top priority for the company executives. We have a hard date this fall that we have to make. If we make your change, we won't be able to hit that. You'll just have to write the code this way." It seemed no matter who we appealed to, all we heard was no.
When the hard date came, 20 to 30 people in the office were needed to roll out the system. After about 10 hours, we'd cut over about 10 percent of our unit to the new system. Not only was the new system quite complicated, but some of the upper managers didn't trust it and refused to switch over.
It took another two years before even 50 percent of our unit was on the new system, and results were similar with other business units throughout the company. In that time, the team working on the back-end product dwindled in number from about 15 people to 3. Some moved on to different jobs in the company, but most left the company entirely.
And the system? Well, more than 20 upgrades were rolled out in those two years. Last I heard, they were thinking about rewriting the entire project from scratch because it's grown too messy. Go figure.
Send your own crazy-but-true tale of managing IT, personal bloopers, supporting users, or dealing with bureaucratic nonsense to email@example.com. If we publish it, you'll receive a $50 American Express gift cheque.
This story, "Cut-throat culture sinks an IT project," was originally published at InfoWorld.com. Read more crazy-but-true stories in the anonymous Off the Record blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.