The portal story

I get an adrenaline rush every time i work on a new technology. Partner Portal is a project that I am presently working on and it was a nerve sweller for me, because it involved working with Spring MVC and Spring Slices, a technology different from all the other ones used in my organization. While it is the technology that makes this product unique for me, this post is an account, of what this project means to people in our company, the way I see it.
Being a new product, partner portal has different implications for different people because of the changes it brings for them. There are four sections of staff who are primarily impacted by partner portal in the process of its development, other than the developers:
1. BPO
2. Product
3. Creatives
4. QA
1. Changes for BPO: Till now BPO has been using Oracle reports, which allow for insert update and delete on Oracle databases and is very efficient. Somebody, at sometime, at some place felt that improved look-n-feel is more important than performance, even for backoffice tools. This thought led to conception of partner portal. An application which relies on Ajax, Jquery, Spring AOP, Spring Security, Spring MVC to furnish the same functionality that can be delivered by oracle reports, in perhaps half the time, but can be programmed to have a classy look and feel, with very rich features, and an amazing user experience.

In other words: Our backoffice tool is expected to be far more rich-featured than our core product, i.e. poker and casino.

2. Changes for Product: Product team attracts a lot of respect in a business oriented organization(ours, for example) when compared to a technology oriented organization (yahoo, for example), reason being, our product's look and feel directly affects the user experience and hence the business. Product team comes in as an interface between technology and business, and a project like this involves product input more than anything else. We have a small joke circling around in partner portal technology,
"We are being asked to decorate our drawing rooms while there is a lot of firefighting to do on the rest of the burning house". Decorating our drawing rooms here means working on cosmetic issues, like text alignments.
I swear to god this is a true incident - we were asked to consider a request(from product of course) where, every time an agent sees a table he is allowed to adjust the number of columns he wants to see,adjust the width of columns he sees and if that was not enough, the application is supposed to remember the width of columns of each of about 100 tables that every agent changes, and shows that column with the same width that he configured in previous session. That for 100s of tables.
Can someone believe that? Has somebody seen that even on social networking sites. Social networking is a neck to neck business. And UI matters most to those apps. And orkut is developed by google, they hire best in the world for that job. But even they don't come up with such crazy ideas. Max they allow is changing the background theme. Perhaps the layout of home page.
Additionally, In a special case like partner portal, product finds it very convenient to not mention their list of demands beforehand, because that is the only way, that they can request for anything that comes in their dreams, and they ask it at anytime of the day.
3. Changes for Creatives: Creatives are perhaps the most underestimated, over loaded and mistreated fellows in the industry, it is true that they have there own set of guidelines, but what I did not know was that it was agreed upon after consultation with product.
4. Changes for QA: A sound technology demands a sound QA. A sound QA is expected to verify all the existing functionality, with every possible side-effect. But how worthy are their efforts? Let me give an example, when a player is marked fraud in his cashier category, his other categories are directly impacted. He becomes fraud by login category, his funds are ceased, he is not allowed to use his pcard (like a parypoker credit card), if he has any besides a lot of stuff. But our highly qualified and trusted QA checks that after a succesful update of cashier category, the message "Updated successfully" should appear in green, with a check symbol infront of it or else they will file a bug. Nobody looks at the other dependencies. If QA hits an idea (about some cool new feature that could have been added, which product could not think about), they take the credit of that idea, while the developer is expected to develop it, and also to be loaded by a bug.

I am at the centre of all such requests, The developer and the creatives take the cane in almost all the cases, and it is the QA and product who take credit of new ideas and features in the product. I don't mind that. At the end of the day, I get to work on Spring MVC, which makes me learn more everyday, than what I would otherwise learn in maybe a month and that knowledge and excitement and joy of working on this new technology is something that I love and thats what keeps me going.