October was a busy month, very, I should say. But that was a productive one as well.
The early part was spent on meetings and OSGi training. The latter half mostly spent on building Java with Maven2. :)
I did not develop very many things, others did. But I helped find a great deal of problems, just by building and running it. First I found that Carbon was not building on Windows correctly. Then after we thought that we have found and fixed the Tomcat corruption problem, I found that on Windows, it was breaking, more often than on Linux. And the guys managed to fix it, but I contributed to help understand the problem. Then the caching problem, to which I managed to find a workaround. Then I was good at finding more work, as an example, I questioned the need for operation level engagement of modules, and that triggered the need to write operation management component.
There are some leaning points from last month.
- More minds help solve it fast
- More people are needed to talk about problems
- Think beyond what you like to see on the screen
- Problems take time to solve
- You need few "bad guys" on the team
More minds help to get it fast. When someone works on something alone, there is only one perspective. When two or more are around, it is far more effective specially to bring in more perspective. We did not necessarily do pair programming, but someone being able to build, have a peak and give feedback is productive. More productive when the second or the third person is on a different platform.
The other important aspect is that, people need other people around to talk about problems. I am not talking about personal lives, rather technical problems. In the early days, Saminda would talk about the OSGi problems that he faces. But there was no one to relate to him. After the OSGi training, we have more people to have an opinion about a problem. As always, I do voice my opinion. So do a handful of folks. So it is far easier to get to the root of the problems.
It is also important to think beyond what you like to see on the screen. When getting to the bottom of the Tomcat corruption problem, Sameera and I was editing the config.ini many a times. And we knew for sure that the problem was with the config.ini, because the previous worked while the new did not. However, we were too smart to think that the problem was in the bundle manager, and the ordering differences at the top of the new ini file. We never looked at the last two lines of the config.ini file and question them what those were. Had we done that, we could have reached the solution faster.
Some problems, no matter how much you like them to be solved faster, takes time to solve. When we first look at a problem, the first thing that we try to locate is that if we have hit a similar problem earlier as well. And even if we find even a slightly similar pattern, we go after that even the problem and the solution might be drastically different. That is because we do our pattern matching, and we try too fast to make a match, even there are slight mismatches. Later, when the patterned solution does not work only, we see that the slight mismatch had the clue. And it takes time to go back and forth.
When you are working on a tight deadline, you need few "bad guys" on the team. Usually, in a tight deadline situation, all people are busy with the work they are assigned. Even architects have their assigned work. So they keep their heads down and work so hard to get the job done. However, in that mode, you can easily loose sight of the big picture. It is for this reason that you have project managers in a team. But how often that you see that, even with project managers, that you see deadlines being missed. That is because, the PM did not play the "bad guy" role, and most PMs can't. Often, the PM plays the "ugly guy" and not the "bad guy". The "bad guy" is the one who ask the wrong questions at the wrong time, and the one who tries things out with the end product, before you are supposed to. Most of those questions could be very wrong and can be easily discarded. And most of those use cases being tried would be not applicable. But it is important that "bad guys" look into those "you are not supposed to" things early and often. It is more important that others do not just discard the concerns and at least listen to them. And you do not need to have only one assigned "bad guy". All tech folks can take turns and play that role, and no, I am not talking about QA folks. The "bad guy" role must be played by engineers, working with the code. If you do not have people playing the "bad guy" role, you would still find those problems, but might be a bit too late. "Bad guys" help you find problems early and often, in a tight deadline situation.
Comments