Monday, November 15, 2010

The Usual Suspects

I'm back again working for a Software Services Organization. This one is maintaining a mission critical, complex application for a mining giant in Western Australia.

It's quite astonishing to see that the same problems we solved (or tried to solve) as a small Sri Lankan outsource based software services company is being solved each day over here as well. The dynamics are pretty funny sometimes.

The architecture of the application itself is a problem of its own. The product is based on a heavy Oracle based back-end which handles almost 80% of business logic. In addition it handles a lot of other integrations with 3rd party systems. Meaning instead of classes with 1000 lines you get stored procedures of 10000 lines. The front end is migrated from ASP.Net Web Forms to MVC few months back and shows signs of a mixed back here and there. The development team is around 15 people and true to its heavy Oracle back-end it has 10 Oracle developers and 4 .Net developers. In additions there's a big team of BAs, Testers, Architects and Managers trying to create work for the rest of the team and vice versa.

The development process is more close to Agile than it is to RUP. But it's very loose agile and kind of sloppy as well.

All the usual suspects are seen everyday, and I can't help getting nostalgic a little bit. Here are few common problems we face.

1. Heated discussions about the development process getting heavier each day. (Jim says that he needs 30 minutes to fix a bug and 1 hour to fill the bug report details)

2. Incomplete and inconsistent specs (I didn't document that requirement 'cos it's so obvious)

3. Plethora of support environments (We need 3 more virtual machines next week for the 3 enhancement testing)

4. Lot of context switching (Mike, I need you to stop RS334 and work on TS122 for 2 days, then start on RS335)

5. Deployments take time and they are done each week (Chris, let's start the deployment today so that we could finish the release tomorrow)

6. No graphic designers => Developers cramming away with CSS/HTML. (Why do we need graphic designers anyway? asked one Oracle Developer)

7. And finally... the silver bullet - Re-Architecting the product (Our 3 architects are working on an improved architecture which will solve all the problems in the product, said the PM with a big grin)

On the other hand there are some very useful things done in the project as well. The use of 'Mercurial' as the source control (Distributed Version Control) is interesting. So far I preferred its flexibility to that of SVN. Also the non-use of ready made user controls and sticking to good ol' HTML is very interesting. This had actually provided the product with a great performance gain, which was essential.

As a new comer to the project, I have lots of opinions about the way things are done and may be how they should be done. But it's not only legacy code which is hard to change, legacy practices are the same. My strategy is to take things slowly, chances are there's a good reason for doing the things like they are. I just have to find that reason and change it...or may be not :).
Post a Comment