Team Dynamics - part 1

I'm pretty sure this is going to be the start of a series of notes on my experiences with the various teams as they progress through the project.

Communication:

My most favorite team (i shouldn't be saying this), but in my eyes the most strongest team, started out really well. They were very eager to do the right thing, and produce results. They worked cohesively to capture requirements and produced a very good requirements spec.

However when we started the design phase we started experiencing certain crucial problem which actually hampered their progress.

- The team was too enthusiastic in churning out code that they didn't think through the design thoroughly. They were quick to start coding certain sections of the code. While coding they realized there were gaps in their design. This resulted in many many discussions around certain areas of the design which were not thought out properly, which resulted in a lot of rework. This was probably due to the fact that they had to produce both a Java api and a C++ api as well.
- There was a serious communication gap. What i mean is that each person interpreted the design in their own way. They did not stop to debrief and consolidate their understanding. This too was a major reason for the many design discussions.

Result: They didn't achieve the level of efficiency they would have liked to achieve. This resulted in them falling back on the schedule.

How we overcame it :
- Took a step back. Went through the design, step by step without taking anything for granted.
- Ensured that we all had the same understanding.
- Shared the effort of documentating the sequence diagrams.

Service Data Objects

One of the projects i'm involved in requires us to design and implement a generic "data container" such that any client could use it to store and retrieve data. Thats not all, if required, the data in the data container should be serializable in the form of either XML or some other defined format. In addition to that, the data container should be inter-operable, that is once serialized a different client (c++ or java) should be able to de-serialize it and use the data within. Pretty interesting stuff.

While performing my initial research for the design and implementation, i came across 2 strong technology contenders. JaxB and SDO. Ideally you cannot compare the two as they serve two different purposes. But i will explain why i used those names in the next section.

JaxB provides a very easy way to bind data to XML in a static manner. That is, the objects have to be generated before hand and included in the classpath. Once an XML document is received the JaxB api allows us to deal with objects rather than xml elements. However, we had to provide the client the flexibility to create objects dynamically - on the fly. Therefore, for dynamic object creation, there was no way we could have the classes ready before hand. Therefore static binding will not satisfy this flexibility requirement.

This is when i came across the Service Data Object spec. SDO's are built for this purpose - to contain data. And after more research, i found out that all SDO implementations (IBM, Apache and a few others ) are based on EMF (Eclipse Modelling Framework). EMF provides the facility for both static and dynamic binding. Therefore with SDO, a client could create an object on the fly, generate an XML out of it (no XSD required) and vice versa. Pretty cool.

Deciding on subversion access priviledges...

As part of setting up the infrastructure for development we had to set up and configure subversion as our source control repository.

My initial thoughts were to provide read write access to all developers to all projects. My rational behind this was that, we were all adults and that there has to be some discipline when checking in code. As in no one would check in broken code.

However, after speaking to some of the team members it became apparent that most developers were new to this concept of working with a code repository and that they most probably would lazily check in code without ensuring their changes would cause a break in the build. Therefore, lets give each developer access to only their section of the codebase (frontend, backend etc).

Ok, thats understandable. i can live with that. After all prevention is better than cure :P

However there was another school of thought that brought up this very interesting proposal. Since these developers were new to this practice, why not give very specific access privileges. I.e. class level. Wow... i had never thought of this.

Personally, i don't think this is practical at all. It would be a nightmare trying to manage access privileges as developers finish a particular class and want to add/edit another class. And wouldn't this be a serious bottleneck to development ?

Interesting argument.. how far can you go with prevention ?? :P:P

Interviews...

Over the last three weeks I've been interviewing with a certain company. The interview process has been very interesting. At each stage the interview questions just got harder and harder. I guess thats the norm. Its just that its been quite a while since i was subjected to this kind pressure, and to tell you the truth, i truly enjoyed it!

The questions ranged from data structures,
- Where they test your ability to select the most appropriate data structure to solve a problem
- awareness of common data structures and how you would traverse through them

To some really interesting algorithm questions like,
- write an algorithm where given an array of numbers (ints) , find the number of pairs that sum up to a given number.
- given a n by n matrix or integers, where each row is sorted in ascending order and each column is sorted in ascending order. Find a particular number in that matrix.

The question is fairly straightforward. However, they are not looking for the regular question anybody would give. They are looking for the smarter ones who think about more optimized ways of executing this algorithm. Therefore, the next part is generally focused around complexity.

The last interview was the most toughest. It covered all areas including, scalability concerns, fault tolerance and fail over, performance and availability strategies. All in all, whatever the outcome, I thoroughly enjoyed the experience. All of my interviewers were very easy-going friendly people who had the knack of setting the interviewee at ease.

Heres a link i found pretty useful,
http://discuss.techinterview.org/?interview

Microsoft Vista Review: It sucks !!!!!

Note: I am trying to be as unbiased as possible.

I installed Microsoft Vista two days ago and I'm already sick of it. I can't count the number of times its annoyed and frustrated me. This is perhaps the worst operating system i have ever used.

Please note that my machine spec isn't all that bad (1.5Gb Ram, T2400 1.83GHz Processor)
Installation procedure: Upgrade.

Here are some of my experiences,
- Ok, when you first look at it, it looks good ! They have done a pretty good job of *trying* to look like Mac. That is what drove me to install it. But don't be deceived!!!
- A simple right click is so unpredictable. If it does decide to appear, it appears in what seems like hours.. ok not hours but at least ~40-50 seconds - Not acceptable
- Out of the 6 times i have booted my machine, on two occasions the desktop rendering was weird. The icons had disappeared and there was no task bar.
- I have administrator privileges. On several times it displayed a dialog box stating that i have no privileges to access files on my disk. Ok, this was experienced while installing MS Office 2007 :)
- If i enable all the goodies and animations overall performance suffers drastically. I have now removed all of its fancy graphics and animation.


To top it all, its soo difficult to uninstall. I am now in the process of reformatting my machine and reverting back to XP.

Recommendation: STAY AWAY !!!

The Grid Project Begins...

After much anticipation, the Citi-UCL collaboration project was finally launched on the 30th of April 2007. We had our preliminary meeting at Canary Wharf – Citi’s Investment Banking headquarters in London. This was followed by another meeting, at UCL, to further discuss the project scope, team organization structure and grading criteria.

We all decided to meet up after the project brief and proactively take the first steps towards launching the project. The Project Manager – Andy and Technical Lead – myself, were chosen to lead the team.

Since most of the team were fairly new to actually taking on and executing a project, I stressed on the importance of selecting and then adhering to a software development methodology (process) that would ensure that we engineer the project in an organized manner.
We swiftly began our project initiation activities,

- Formulating the team - dividing the team into 3 sub-teams. Each sub team was responsible for the requirement gathering, design and implementation of their sub-system.

- Researching and then defining a suitable software development process that would suit our project size and experience, and wouldn’t be that difficult to follow.

- Define templates that the team would use so that, all deliverables would be consistent.

- Define a problem statement, so that we could validate and clarify our understanding of the project, and act as a mechanism to trigger more discussion around requirement gathering

H1B Saga