The blog of a not-so-young software developer

Year in Review

2006-01-02T11:53:00.000+08:00

2005 has come to an end. For me, this would be the year where the most contigencies have happened, and almost impossible to plan. Or perhaps I should use the old saying: "What man proposes, heaven disposes".

My friends and colleagues would know that I'm the type who likes to plan ahead, be it the annual vacation, getting married, moving house, etc. But this year, the guy upstairs seems to enjoy throwing things in the way of my plans.

Well, my wife and I have been planning to start a family for quite a while. Things haven't been happening quite as planned, so when my project work provided an opportunity for me to be posted overseas, my wife and I agreed that it would be a good break for us (to get away from the pressures to procreate, to allow me to focus on just one project and in technical work, to nudge my wife out of her comfort zone for a while).

Just 2 months before our departure, my wife and I had the good news we were waiting for. It was like the last month that we "let things go naturally"; if we had missed this one, I'd not be typing this from my home now.

So, we had to backpaddle and put an emergency brake to the posting, make adjustments to both our work (my wife has already obtained the no-pay leave she requested and started to hand over some of the work; I had to explain to everybody that I'm not going after all and make arrangements for the project and my workload).

Because I was not going overseas, and because of my dis-satisfaction with my involvement with this project, I started to request for transfer to other projects, getting the project manager to sort of agree that I will transit out by the next milestone sometime in 2006.

Just as I was happily washing my hands off the project, my project manager had some personal issues with his family, and had to be away for quite a while. And I had to cover his project management duties, an instant reversal of my planned extrication from this project.

This took me all the way to the end of the year. Come 2006, I'm not planning for anything, just waiting for things to come. What with my first baby coming, and still not sure when my project manager will be back fulltime on his job, all I can do is to take things one step at a time.

Wishing one and all a happy, healthy and fruitful 2006.

Software Project Manager's Handbook by Dwayne Phillips

2005-10-25T09:41:00.000+08:00

So Dwayne says that project managers must basically like to work with people. I guess most of the project managers become project managers either because they are good at technical work, or simply outlasted the competition (i.e. stuck around long enough).

Come to think of it, most professional services industry suffer from the same thing (accounting firms, law firms) ...

Recent Updates

2005-10-24T22:57:00.000+08:00

Have not updated blog entries for a while. Guess I've gotten over the peevish stage with my Project Manager, so have not had the emotional upheaval to require an outlet to write.

A combination of factors helped to resolve my bout of peevishness. I was supposed to be posted overseas for a stint, but things came up at home that I had to cancel the trip. The trip would have helped to reduce the friction between the project manager and I, but now that it did not happen, I was thinking about making a shift to another group, when the director (our collective boss) talked to me in the corridor and mooted the idea first. His concern, rightly, was that there isn't a clear role for me in the project. I was pretty much like a "deputy" project manager. I am rather grateful to him for making it easier for me by initiating it, instead of me trying to raise the issue without hurting anybody, especially myself. Anyway, so I am moving out of the project after the design phase.

This provided an opportunity for me to raise the issue to my project manager, and I also made use of the opportunity to scope out a "role" in the team, in essentially the simulation team. With this, I deliberately chose to skip the customer's project management meetings. Skipping the meetings helped, because when I attended, I became essentially the "messegner boy", and often felt the pressure from the customer because of all the issues that remained happily outstanding in the project manager's lap. Now, they are breathing down HIS neck, and rightfully so, as I did not have the authority to direct the project resources anyway.

Strange thing is that, now that I'm staying away, the idea of attending these meetings no longer irk me as much, and I do find myself attending some of them recently. I should remind myself not to get overly involved again. Like the Chinese saying: "Distance is Beauty".

It is working != It is correct

2005-09-16T23:11:00.000+08:00

I wonder how our local universities teach programming. Wait, I am a product of these universities ... well, guess I can only say that they're as wanting as before.

A couple of weeks ago, I had to lecture one of my junior colleague, just out of U. It's not because he's not good, or the code's not working, but something just got on my nerves. Maybe I should illustrate with an example.

Light, as we know, comprises 3 primary colour components. So, we can have a CLight class which has 3 CPrimaryColourComponents. Each CPrimaryColourComponent has a integral value denoting the intensity, and an enumerated type that states whether it is BLUE, RED or GREEN.

We can have

enum E_COLOUR_TYPE
{
RED = 0,
BLUE,
GREEN
};

In fact, this was defined, in a header file that includes a whole bunch of other stuff that is totally unnecessary for the simple remote data sender/receiver thing I asked him to write. So, I used integer instead, something like:

class CPrimaryColourComponent
{
public:

int getIntensity() const;
void setIntensity(int intensity);

// 0 for RED, 1 for BLUE, 2 for GREEN
int getColourType() const;
void setColourType(int colour);

};

class CLight
{
void setPrimaryColour(int colour, int intensity);
const CPrimaryColourComponent & getPrimaryColour(int colour);
};

Initially, the code looks fine. We were doing stuff like

CLight myLight;
// ....

myLight.setPrimaryColour(0, 23);
myLight.setPrimaryColour(1, 44);
myLight.setPrimaryColour(2, 32);

// ...
int redIntensity myLight.getPrimaryColour(0).getIntensity();
int blueIntensity myLight.getPrimaryColour(1).getIntensity();
int greenIntensity myLight.getPrimaryColour(2).getIntensity();

My mistake was that in the portion of the code that marshals the data across to his module, I got lazy and directly cast the integral value of the CPrimaryColourComponent's ColourType to the enumerated value, e.g.

E_COLOUR_TYPE colType;
int colIntensity;
// ....
myLight.setPrimaryColour(colType, colIntensity);

CPrimaryColourComponent = pcComp;
// ...
E_COLOUR_TYPE pcType = pcComp.getColourType();

In CLight, there's an array of CPrimaryColourComponent, each element holding 1 CPrimaryColourComponent, indexed by the Colour type (Like I said, this was meant to be a simple stub thing).

Of course, after a while, the E_COLOUR_TYPE had to be changed to

enum E_COLOUR_TYPE
{
RED = 1,
BLUE,
GREEN
};

Instead of changing the mapping routine which I have passed to him for maintenance, he changed the implementation of CLight::setPrimaryColour(...) such that now, we call

myLight.setPrimaryColour(1, 23);
myLight.setPrimaryColour(2, 44);
myLight.setPrimaryColour(3, 32);

However, the portion to retrieve the colour components was not changed:

int redIntensity myLight.getPrimaryColour(0).getIntensity();
int blueIntensity myLight.getPrimaryColour(1).getIntensity();
int greenIntensity myLight.getPrimaryColour(2).getIntensity();

Essentially, the CPrimaryColourComponent array index was offset by 1 in the set function, but not offset in the get function.

I exclaimed that one cannot design a class where setPrimaryColour goes from 1 to 3, and the getPrimaryColour goes from 0 to 2. It's plain inconsistent and confusing.

The strange thing was that he found me somewhat puzzling. He was probably thinking what's the big fuss, the code's working. He also thought I had wanted to access the array with an index from 1 to 3 and expressed concern about wasting one array element. I had to tell him that it's got nothing to do with however he intends to store the CPrimaryColourComponent instances, but it is wrong from the CLight interfaces.

Until now, 2 weeks on, I'm still not sure he got my point ...

2005-08-31T10:49:00.000+08:00

I feel like dirt.

I found out I'm going on an overseas trip this week. How? My colleague SMS'ed me when I was on course 2 weeks ago to ask about the validity of my passport.

Then I found out the arrival and departure dates. How? Another colleague emailed our overseas rep. A word document attached contains my name and the dates of arrival and departure.

Then I found out we couldn't get seats on the intended departure date (ex SIN). How? During a casual post lunch conversation with the first colleague.

Today I found out that because of the 2-day delay, my boss is extending the trip across the weekend (it was originally for 5 working days). How? Well, the first colleague just told me when we're in the lab working.

The strange thing is that there is no agenda set yet. So why am I going? In case they need me? Because I'm good at everything? So that my boss can throw me things he doesn't want to do?

5 minutes ago, I found out that the admin girl helping with the ticket arrangement isn't informed of the extension. I'm 101%, no 99.999% sure (leave myself some room to wriggle) that hotel arrangement isn't updated.

So far, my boss has not come to me and inform me that I am on this trip (although we ALL ASSUMED I was), when, and whether I can make it. I have to go around getting information from others.

Am I a machine? To be moved at will? To be switched on and off at will?

Should I feel like dirt?

Barriers to Project Planning

2005-08-28T23:26:00.000+08:00

A common situation in planning is that people do not want to spend the time and effort to plan. They are paid to build systems and write software, not plan. These people do not like to plan and they do not plan well. This combination means that they often delay planning until the last possible moment or beyond.

Some people defer planning, hoping that additional information becomes available. Some think planning is a waste of time, because things always change anyway.

Planning well takes time and effort. Thus it is important to "plan to plan". Often, planning is done during the "spare time" of the project managers who are often on other work assignments. Effort spent on estimation, budgeting, and tasking is not accounted for. It is little wonder then that the project plans are sketchy at best.

A related problem is that project management is not perceived to be real work. When activities do get planned, few if any, actually plan in project management activities. Aside from schedule, there are many plans in a project, e.g. scmp, sqap, rmp, etc. Project managers often asked “If I had to do all that, how am I going to do the real work?”

These people fail to see why the plans came about in the first place, and/or refuse to give up their selfish desire to do technical work. They do not care/think that the project and the team members suffer because of the lack of planning.

There is an example quoted in the book that describes the consequences when project managers do not take time to plan. I'm sure many of us can see ourselves in such situations:

“People were in the middle of flurries of unplanned activities. Since there was no plan, people were confused as to what they should be doing. Since they were confused, they were too busy to make the plan. This cycle repeats itself endlessly.”

Another common situation quoted in the book is that Project Managers are asked not to plan, but to cook up a “right answer plan”. Someone with authority dictates the deliverable milestones. Hence planning became a farce to arrange (and shorten) tasks to finish on the dictated date.

"The project begins, the dictated deadlines passes with no deliverables, and everybody lives in agony until they finish."

The funny thing is people tend to accept dictated plans, and try to make them work. This is because
· such situations occur so often it becomes normal;
· the dictator is the boss; nobody likes (has the moral courage) to cross the boss.
· people no longer believe in the plan; these disengaged staff just work silently and watch the inevitable happen.

A related phenomenon is what I call "hysterical optimism", where people become overly optimistic about the schedule, timeline and resources.

Very often we fool ourselves into thinking “The people will come on board.” Or “The other subsystem will be late”, “we’ll get the money from somewhere else” and the infamous "I think we can beat that date."

There is no basis to these assumptions, hence "hysterical". One possible reason is that these people are pressurized into coming up with the "right answer plan" and become delusional. Another reason is that they are by nature overly-optimistic.

Goooogle me!

2005-08-20T11:16:00.000+08:00

Hey, I'm on Google!

Project Planning

2005-08-20T11:15:00.000+08:00

Planning starts when the Project Manager realises there are tangible items to be delivered by certain dates, identify certain activities needed to deliver these items, and assigns people to perform these activities.

For all but the simplest projects (e.g. a weekend BBQ for 8 friends), this is insufficient.

Firstly, time is not taken into account. Items have to be delivered by a certain date, meaning that activities would have to be done by a certain date, meaning that they need to start by a certain date. Furthermore, some activities need to be performed in sequence. Without planning, people may start certain activities to find that they do not have the necessary input. Some may finish their activities and discover that nobody wants the things they did yet. Some activities may start too soon, and some too late.

A very typical example of what happens in projects was given in the book.

“Gamma had a high level plan. The PM or system engineer used it to sell the project to their managers. The plan was on a view graph. After approval, they never replaced these viewgraphs with a real plan.”

From the beginning (6 months to 2 years ago) till now, I have not seen the “real” project plan. However, I cannot go to the PM and say that the project plan does not exist, because they will point to the high level plan.

Because of this, I feel that there should be 2 project plans. A high level plan with 1 or 2 levels of WBS and the major milestones is used for the customers and stakeholders. For the project teams, activities should be at individual level with duration at the week level. For big projects, this may require several cascading levels perhaps projects within projects (or programs in this case), but it is essential because ultimately you are telling somebody to do something by a certain time.

Quality Rants

2005-08-17T23:05:00.000+08:00

It's been almost a month. I would have written, but was really really caught up with work and some personal matters. (Yes, programmers lead a normal life too.)

Recently, on National Day (Singapore, 9 August), saw an ex-colleague's article appear in the newspaper's "Digital Life" supplement. It was about software Quality. Somehow, everybody seems to equate software quality with software quality processes, like ISO or SEI CMMi stuff. I think people who think that is missing the whole big point about quality.

I remember meeting Linda Rising during a Design Pattern workshop in Sydney in 1998. She was talking about Christopher Alexander, his book "A Timeless Way To Build" and what he mentioned about "Quality without a name". Now, I have not read Alexander's book, so I cannot comment on how I interpret it, but if I went away with the impression that it's about doing something, and the knowledge deep inside you that you know is good, and gives you pride and delights you.

And I think this is what it's all about.

Malcom Baldridge and SQA can say "quality is defined by the customer". Some people say 6 sigma means good quality. But as a technical person who's doing what he doesn't really enjoy doing most of the time, I think that QWAN thing is closer to me, and remains the Holy Grail that I am searching for.

"It is the search for those moments and situations when we are most alive" so Christopher says. Aye.

Trouble publishing from Office

2005-07-18T23:20:00.000+08:00

I seem to have some problem publishing blogs from my office PC. Everyting is ok until I hit the "Save as Draft" or "Publish Post", and I get this page that says the page cannot be displayed (in IE6) or "This page contains no data" in Firefox.

And then when I try to http://www.blogger.com, or use it's IP address, the page will not load (can't seem to establish connection). But it's ok accessing my blog page http://halfamugobeer.blogspot.com

Hmmm ... does anybody know why?

It sounded good when we started ... Dwayne Phillips and Roy O'Bryan

2005-07-12T12:45:00.000+08:00

The title of the book caught my eye when I was in the
library. So I picked it up, and it proved to be a book
that's easy to read. So over the next few blogs, I'll
try to capture a few points that I find
meaningful/applicable/that I can relate to. Nowadays,
when I write documents, I like to write what we intend
to do and what we do NOT intend to do because readers
seems to assume/imply that we do more than what we
intend to do. I do not intend this to be a book
review.

Proposals

I agree that for most projects, we do "short selling",
i.e. we sell something that we do not have yet. Of
course, the name of the game is to fill up the goods
at a price cheaper than that we're selling. And of
course, that doesn't always happen. The authors write
about builders who propose beyond their capabilities.
Sometimes, it is a case of the customer trying to
"squeeze" the vendors for more "goodies". And it is
not always the ability to deliver, but the pricing of
the contract is so low that the project manager has no
choice but to cut many corners during the project.

I also agree that builders should decide if contracts
are worth winning. Many times, I hear comments from
the upper management like "I know the price is very
low, but we'll lock in the customer, and we can charge
more for subsequent phases". Or "the customer has many
projects in the pipeline". Or some even more obscure
"strategic interest" of the company. Often these same
managers will persuade the poor project manager to
stay within the budget of the project, and gently
breathe down their necks if the project were to make a
loss/delay etc. In so doing, instead of "locking in"
the customer, they pretty much ensure that the
customer will stay away for a very long time after
that.

By the way, if I were the customer and I'm trying to
"squeeze" my vendor, I'll also say things like "oh,
we're planning a major upgrade to ", or "if this
turns out well, we have a good case for putting up
budget for company-wide roll out ...". Who's to blame
who if this doesn't turn out? "Oh, yeah, we WERE
planning to upgrade, but y'know the oil prices are up
and we have to trim our budget blah blah blah ...
maybe next year when things get better ... by the way,
do you suppose you could put in a trial license of the
new features you were talking about? Maybe that might
persuade my management ... no guarantees though"

If I were the project manager in this case, I'd put up
a realistic estimate of the cost/effort of the
project, and insist that somebody up there agrees to
commit to THAT cost of the project. Hopefully this
will make them wake up to their unrealistic idea. At
least I'd make sure somebody else's neck gets warmed
up as well...

2005-07-08T23:36:00.000+08:00

We know the saying "death by meetings". My project suffers from the
opposite. The last time everybody updated everybody else was, oh, about a
month ago?

My project manager prefers to have 1-on-1 meetings with the individual
developers, mainly to discuss the technical aspects of the module they
are working on. Things like, should we use explicit acknowledgement for
the communications module? Should we use hashmaps? What persistent
storage should we use? Or the interfaces provided by "framework" classes he developed.

My guess is that he does not want to waste the precious time of other
people, since most of the discussion is very specific to the the module
each individual is developing. So he probably pass on information that
he thinks the developer needs to know in these meetings too.

I am not responsible for any module. So, if he were to keep me in the
loop, he would have to either bring me into every discussion, which is
what he wants to avoid in the first place, or just tell me the stuff
that I need to do. Actually, he doesn't do either. He doesn't tell me what
he told the people, nor tell me the stuff that I need to do, cos I'm
senior enough to figure out what to do without being told. Somehow I
don't feel flattered.

One thing I *think* I'm supposed to do is to "provide guidance".

How?

Every now and then, I get one of them to come up to me with one
question or another. Like should we have a common way of sending functions across different modules, or should something be a synchronous or asynchronous call. And because I've been left out of the picture, sometimes it's a bit hard to call.

I also think that this practice makes the developers feel very "compartmentalised". They are just concerned with their own modules. Once one of the developers started making certain assumptions about another module. I had to question why she did that, since the person developing that module is less than 10 meters (or 30 feet) away. A quick check would have given her all the answers she needed without having to assume.

I also find it a bit hard some times to make recommendations to these
developers because I'm not sure what has transpired between the PM and
them, and I might be making recommendations on the side that is not
consistent with what the PM said. Of course, I can always check back with
the PM, but I prefer to refer the developer to the PM directly; anyway
he's technically more capable than me.

But that said, I cannot be the one who calls these meetings, for I
would be overstepping my role. Guess I'll just have to let things be at the
moment... ...

"It's easy ... just use Singletons!"

2005-07-06T00:20:00.000+08:00

This came from a senior developer of our collaborator when we were discussing about whether to have a builder class to "put the pieces together", so to speak. Instinctively, I felt alarm bells sounding off, but couldn't quite put it coherently why it is a bad idea.

Somehow I wish that the GOF have left out the Singleton Pattern from their landmark Design Patterns book, because it is about the first book that anyone starting on Design Pattern would read, and the pattern is one that anyone reading it will easily understand. And use. A lot.

I remember being in a class on Design Pattern (about 7 years ago?), contorting my mind about how in the world does one use AbstractFactory. My face must have been contorted too, judging by the concerned look on the trainer's face. Then, when we reached Singleton, it felt like enlightenment. Aha! Here is a pattern that I could immediately relate to. I could now show off to my project manager that with a neat trick, I have no global variables to mess around with. Everbody knows globals are bad right? (Hmmm, can't seem to remember why though ...)

Yes. Singleton got rid of global variables. Some would say that global variables are now disguising themselves as singletons. Singletons do share some of the downside of globals, which I will attempt to list as I trawl the net for more ...

1. The good thing about Singletons (and global variables).
Before singletons came along, global variables provided easy access to objects and data that have to be made accessible to many. Else you'd have to have a reference being passed back and forth, up and down just in case some module somewhere needs it. So, global variables were convenient to use. Too convenient, some would say. For when we say "easy access to many", how easy is easy, and how many is many? Thus when we talk about bad ideas, it is usually due to abuse, misuse or over-use of a good one.

2. Namespaces
One of the main problems with global variables is the potential conflict in names.

Imagine we have a global FileLogger which we affectionately call theLogger, that logs messages to a file. Now because of increased functionality, we decide that some modules that relate to some other functionality should log to a different file name. We create another global variable and call it ... ... theLogger. Yet another developer (who's new and hasn't really been told about the logger thing) wrote something like
void doSomething ()
{
FileLogger theLogger("MyLocalLogFile.txt");
// ...
}

Some coding conventions do attempt to resolve this by stipulating that all globals should be prefixed with "g_" or something similar. The use of namespaces in C++ further helps to scope and avoid name conflicts.

This is an area where using Singleton helps. A Singleton actually enforces the fact that there can only be at most 1 (or whatever number you design it to be) singleton instance in the whole system.

3. Design issues
Because Singleton removes the stigma of global variables, many often use it as a matter of convenience. Now, all of a sudden, I can make all my long-living domain classes singletons, I no longer have to pay attention to who needs to talk to who. If class X collaborates with class Y which delegates some responsibilities to classes Y1 and Y2, class Y no longer needs to furnish classes Y1 and Y2 with a reference to X, because everybody knows how to get X. This may actually reduce coupling, because now Y does not need to know X anymore. In fact, singleton classes become islands in class diagrams, because nobody needs to establish any structural association with them.

This makes it diificult to keep track of the clients of singleton classes because it is not apparent from the design diagrams. Furthermore, because "eveybody knows where singletons live", it becomes very easy, especially if you're rushing to meet the code freeze date for that new functionality for which you're assigned, but not really sure which class(es) to assign to, to pull singletons from everywhere to do whatever you need to do, without seriously thinking about the software design and architecture.

Another issue related to "everybody knows where singletons live" is the assumption about the clients of the singleton class, especially if the class was not designed to be a singleton (or rather for universal access) in the first place.

A Logger, for want of a better example, is typically designed to be used by another other class that performs some generic logging function. On the other hand, an EmployeeRecords class may have been designed to be used by some HR functions that does retrieval and update of 1 record at a time, indexed by the employeeId. It being a singleton does not mean that it supports a management query function to list all employees who have been in the company for more than 5 years, or the payroll client to retrieve the bank information of the employees who have yet to be paid their expense reimbursements. Depending on who owns the code and the software development process (or lack thereof), we may have a situation of the EmployeeRecords providing many specialised services. In this day and age of personalised service, I wonder if that may not be a bad thing...

Of course, bad software design exists way before the days of singleton, but singletons make it easier to rape a class.

I've seen a Layered Architecture broken because of the over-use of singletons and global references. The developer was rushing a deadline, there was "no time to do proper design", and we know how the code ended in an italian restaurant. Guess who's staring at the plate? :(

4. Memory Usage and Life cycle management
I see this as more of an implementation issue. Should we instantiate it on the stack? It's a waste if it is not used. Frankly, I think that's a lousy argument. If you're not sure it would be used, why make it a singleton in the first place? The more difficult issue is the order of creation of static objects in different translation units, so if you've got singletons that require other singletons, then you may be in trouble.

Then, if you're using C++, there's the memory leak problem with the original GOF example, which doesn't really bother me, cause it happens only when the program exits, but if you insist, well, there's the Meyer's singleton which cleverly puts the object in the static local variable in the instance call.

There are also issues with the order of destruction, with some using the atexit function that performs calls in the LIFO manner. Of course, that's provided we know whoever's created first wouldn't need something that's created later when it exits. I haven't thought about this much, but what happens if this happens? More reading needed ...

5. Limited extensability of the singleton class.
In the original GOF pattern, the constructor is made protected, so that the singleton can be extended through inheritance. So you have a BaseClass, and there are classes doing BaseClass::instance() to get a BaseClass instance. To allow subclassing, we'd need access to the BaseClass::instance(), modifying it to return the DerivedClass instead. Of course, if we had known earlier, we could have placed the BaseClass::instance() in a separate translation unit (source file) to simplify the build.

6. Unit-Testability of the client class.
The limited extensability of the singleton class also limits the testability of the client class, because it is potentially harder to provide a stub in place of the actual singleton class, unless we own the code. Imagine the class under test needs a reference to BaseClass. We could have easily provided a MockBaseClass that inherits from BaseClass and pass that reference to the ClassUnderTest. But if it calls BaseClass::instance(), and BaseClass is part of a bigger library needed for other stuff, then we'd need to work with the actual BaseClass.

Another problem I've faced is in some distributed computing nodes where services in a node talk to peer services in other nodes via some protocol. When I'm doing unit testing, I just want to test that one class, without dragging in all the supporting services for a remote connection. Unfortunately, the clients and the class itself are singletons, which means I could not now create 2 instances of the clients and 2 instances of the class for my unit test.

Well, it's way past my bedtime, and I'm getting up for a morning run, so I'll just upload this, and edit it again if I can tomorrow ... err later today...

The unOfficial Project Manager

2005-06-30T17:56:00.000+08:00

Had lunch with an ex-colleague on Tuesday, and even she said that I shouldn't leave things undone because they're PM stuff and I'm not the PM.

So, I asked. Do I do all the PM stuff, while he retains the PM role in name? She hesitated before saying that it's better to make things official. Yeah, right.

Frankly, I'm not being difficult on purpose. It's just that I find it hard at times to feel an ownership of the tasks that are quite clearly (to me) somebody else's. Give me a little time ....

******

Posted a question on CM and defect tracking on Joel Spolsky's forum. So far only 1 comment. Anybody else can contribute?

Lessons from Star Wars Episode III

2005-06-27T14:00:00.000+08:00

(Spoiler warning!)

The thing that stuck most about Ep. 3, is how Anakin Skywalker went over to the dark side. While the Jedi training aims at controlling one's emotions, and the denial of self to serve the common good, the Sith aims at using one's emotions to unleash greater powers to achieve one's desires.

I think Anakin's inevitable fall can be attributed to:

His inability to control his anger, especially the desire to seek revenge.
His ambition, of thinking he's meant for greater things, and his frustration at all who seem to block his way.
His obsession to hold on to what is his, namely Padme and their children.

But isn't that the nature of all "evil", common across all religions? That obsession with self without regards to the common good?

Imagine, if I had been an overaged Jedi apprentice, talking to Yoda ...

Yoda: Very troubled, you've been, paduan.

Me: I'm sick of doing things on behalf on my PM, Master Yoda. I'm not going to do them anymore! I'll just do what I want to do. He can screw up the project for all I care!

Yoda: Very close to the dark side, you are.

Me: You mean, I've to carry on clearing his work for him?

Yoda: Exist to serve the common good, the jedi. Do the right things, you must. Learn to let go of your sense of injustice, you must.

Me: ... ...

Yoda: Patience, paduan. Great things, big sacrifices, follow.

Me: Oh yeah? I expect a big bonus then ...

Gotta go for my meeting ...

RSS, Atom, Syndication & Site Feed

2005-06-27T13:11:00.000+08:00

Being new to the blogging business, I noticed this site feed option here in blogger. Curious, went to look it up, and found an excellent explanation at http://www.mezzoblue.com/archives/2004/05/19/what_is_rssx/

Managing Your Boss

2005-06-26T15:10:00.000+08:00

Started some reading on project management and career management because of my current situation with my project manager Terry. One of the books that I picked up from the library is the Harvard Business Review on Managing Your Career, because of the HBR classic "Managing Your Boss" by John Gabarro and John Kotter.

In the article, the authors told the story about how Bonnevie did not get along with his boss Gibbons, resulting in the company making a loss and Bonnevie getting the boot. The authors further argued that while many dismiss such situations as personality conflict, it was more of a case of an "unrealistic assumptions and expectations of boss-subordinate relationships", that it involves a mutual dependence of 2 fallible human beings.

They then went on to discuss the need to understand both yourself and your boss, to adapt to the boss's working style, ... go read the article.

The part of the abstract on effective behavior caught my attention most: "Forget ambition. Forget promotion. Forget raises. Just think of the job and how to be effective in it."

So ... I'm just supposed to carry on doing what he's supposed to be doing (boring PM stuff), while he's doing what both of us like to be doing (interesting technical stuff)? B-b-but what if I did some of the PM stuff wrong? Who's responsible? Please don't tell me things like 'both of you'. Initially I consoled myself that at least I'm "learning the ropes" to be a PM, without shouldering the responsibilities, but after a while I O.D. on that consolation.

Does the classic article still apply in the 21st century?

Incidentally, I read this article not long after I watched Star Wars Episode III. I think somebody up there is trying to tell me something ... ... but that's for the next blog, perhaps tomorrow?

B-B-But I'm not the project manager ...

2005-06-26T09:11:00.000+08:00

I have a problem. Quite a big one. A very typical one.

It's my Project Manager.

You know how it is in the technical line. People become Project Managers, not because they are good at managing, or even like managing. They often become project managers because they are good at their technical fields, and over time they become the most senior people on the team and that means becoming the project manager.

These people like dabbling in their technical stuff, be it writing software, developing protocols, or designing algorithms. They do NOT like boring stuff, like writing plans, thinking about risk management, attending useless user meetings, and (especially) keying in stuff in the SAP.

So it's the case with my project manager, whom I shall call Terry.

Just to fill in the perspective: I'm the senior developer on the team of about 10. I'll provide more details if needed as we go along ...

It so happens that 1 day I woke up, and realised that I was the one who wrote the SOW (Scope of Work), did the effort and cost estimation, organised contract negotiation meetings and kept track of the many versions of contracts, rushed around like a madman on the eve of our business trip to make sure the business admin department cleared the contract before we leave.

And I decided I've had enough. Why am I the one doing all these stuff, instead of the PM?

A lot of the stuff that I did was on my own initiative. It wasn't something that he delegated to me. He did not come over to me and say "Aloysius, I'm really swamped with work, can you handle the user meetings for me?" No. The users sent notice via email to both of us. I attended and he didn't. That happens long enough, and the users now just sends the mails to me. But I'm not the project manager! Can I commit on his behalf how many of us will attend the tools training? How many of us will support the initial testing? Whether we are going to inter-operate with system A, B or C?

It's the same with the other stuff like SOW, or software configuration management, document repository, etc ...

I guess my main question is: if the Project Manager doesn't care to do or delegate, should I do it on my own initiative? Should I care, if the Project Manager doesn't?

Niel Christiansen on File System Filters

2005-06-24T09:49:00.000+08:00

Was reading the exchange between Robert Scoble and Joel Spolsky on the Microsoft Recruitment issue, and came across a video on Niel Christiansen talking about File System Filters. I like the video, not for the architecture presented, but the insight into the considerations in adopting the first stack-based implementation and the change to the Filter Manager-based impementation.

Come to think of it, the thought of developing something that is used by billions of people worldwide is rather daunting. Imagine the number of people coming after my throat if I did something (inadvertently of course) that results in worldwide misery.

Will dig more around Channel 9 to see if there's more interesting stuff. Later, gotta get back to my design work first.

Well, well, what do you know ....

2005-06-23T14:20:00.000+08:00

"You know," I was telling a friend. "Bloggers are typically egotistic fools who suffer from the delusion that there's an audience for their inane ramblings."

"Hey! That's sounds like me!" I added, excitedly.

So here I am, and the only reason that's been holding me back all this while is the sheer inertia of clicking on the right spot, and thinking of meaningless things to say.

A little pathetic though, to start off my blog this way, if this is all I have to say. Well, I DID think about what I should talk about here -- should it be about work? my love life? my interest? Heck, I've decided to let it just flow and see what happens.

So here's 1 to me!