I was working at a company that was less than united, to put it mildly, thanks to an owner who liked to buy up companies, then pit these units against each other in the name of "development."
Though these units offered products and services for the same overall type of business, they serviced different clientele. For example, one unit might target large corporations, while another worked with mom and pop shops -- but neither was used to collaborating with the other.
The owner further emphasized these silos when developing new products: He had the units face off against each other to see which would get it done the fastest. Redundancy ran rampant, with two or more teams often writing essentially the same product in the race to be the first to market.
When the dust settled, the losing units could either meet with the winner to find out how to make the product work for them or go with their own system and disregard everyone else. They usually chose the latter path. As can be expected, a lot of waste and expense came out of this competitive climate, and it became ingrained in the culture.
New boss, meet old attitudes
A new owner took over the company many years later, which happened to be right around the time I started working there. Despite the new owner's best efforts to streamline the organization and make a single company out of all the competing units, the old mind-set persisted: Getting something done fast was still more important than doing it right.
Under the new owner, one project focused on simplifying internal processes, particularly the numerous accounting and billing systems. We had several people doing the same job but with different software, which made creating companywide reports a real pain, as someone would have to aggregate the data over multiple systems. A back-office team was put together to create a single system to replace the existing setup.
I was on the development team for a business unit that was one of the first to integrate with the new system. The back-office team leader and one developer initially sat down and asked us what we needed for the switch.
We detailed the login and purchase flows that would need to be changed. We drilled down in our code and found about six methods that required replacement. We gave them the method signature and a rough idea of what had to be done. We were told that they'd have this for us in two weeks.
About a month later, we still hadn't seen anything from them. Then one afternoon, the team leader stopped by my cube to discuss the project. He asked me if I had "ever done agile development before? Because that's what we do. You know, no requirements. The developers just code what they think."
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.
This story, "Cut-throat culture sinks an IT project" was originally published by InfoWorld.