Steven Yong's Weblog

The news that excited me today is the new look of netbeans.org website and the final release of NetBeans IDE 5.5 is out. After using 5.5 beta for months, I can't wait to experience what's new in the final stable release.

Over the past few days I've been trying very hard convincing the team to have a more proper defect resolution process. Not to be confused with software life cycle process, it involves only tester/user, manager and programmer and it happens only in testing phase.
As you might guess, I failed. Reason? Same. "We are in critical situation, we appreciate your feedback and we will try to improve the process for coming projects."

Why I said I got the same reply? It is because I heard this kind of reply over and over and over again for time to time in the past few years.

Guess what? When I was giving advices to the management, I was actually working on those "coming projects".

Seems like human being is instinctively not able to do anything useful to help the situation when living under a critical condition.

Dell had its lowest year-over-year growth ever, with its global PC shipments growing 3.6 percent, said Gartner. Its worldwide market share decreased to 16.1 percent, from 16.5 percent in the same quarter last year...

Read the full story here.

After years working on software development, I think developers can generally be categorized into two types, which I call them H type and S type.
Example worth a thousand words, here are the differences of the 2 types:

Question: Can you help to do this for me?

H type: "Sure"
S type: "Can I do it after this?"

Question: Can you draw a data flow diagram of this program?

H type: "Okay, no problem"
S type: "Why? who is going to read it?"

Question: Sorry I'm too busy to report it, can you fix this immediately?

H type: "Okay, will do"
S type: "Sorry can you please report it first"

Question: Hey sorry, customers have just changed their mind, can you remove the full stop from the message?

H type: "Sure, it is easy"
S type: "I thought we've agreed to have the full stop? Are you sure it's going to be the final decision?"

Question: Can we provide this feature? Is it hard?

H type: "Technically it is not hard, shouldn't be any problem doing it"
S type: "Why are we doing this? how can this feature help the users?"

Question: Blah blah blah, this is how it supposes to work, can you start now?

H type: "Okay, I think I know what to do"
S type: "I don't think I can remember exactly what you've just said, can I have a spec?"

And much more...

According to my experiences, most managers or anyone who have to manage developers prefer to work with type H developers (they basically hate type S). Over the past few months, I've conducted quite a number of job interviews, as you can guess, 90% of the candidates fall into the H type. Fortunately, we still managed to hire some who are type S.
So, what are H and S stands for, they are not something that simply created for illustration purpose, instead they literally reflect the nature of both types, which are Helpful and Stubborn.

I will never know which type of developer I'd prefer until I have to manage them. Sad to say, I'm in type S, and I believe I would be more happy if I could switch myself to type H.

• Database table get altered, updating database design spec is skipped, outcome: "what is that additional flag for?"
• A bug get communicated to programmer verbally, entering into bug database is skipped, outcome: "why didn't we accept this special character?"
• An error occured in production environment, reproducing the error in development environment is skipped, outcome: "Are you sure you didn't replace the configuration files on production?"
• A showstopper bug happened and get fixed, checking in the code into source code control is skipped, outcome: "I thought we fixed this already?"
• A new request is accepted, updating requirement spec is skipped, outcome: "why are we giving this feature? how does it suppose to work?"
• There's only a little updates today, daily build is skipped, outcome: "did my fix get deployed last week?"
• A solution for a problem is found, blogging out is skipped, outcome: "do you have any idea why couldn't my program connect to that SQL server?"

People tend to skip and ignore those steps which have no immediate benefits, for him/herself.

My manager was explaining an user experience issue to me yesterday and the conversation ended like this:

Manager: "The problem is only being raised now because previously the consultant who had left was communicating this with users and the outcome didn't get documented down anywhere. So we have no proof for not fixing this"

I: "I see, ok I will make the change once I got the bug reported"

Manager: "Must I enter this into bug database or I can just..."

I: "Remember, we're struggling now because we didn't do it previously"

Manager: "Oh, ok ok"

No offense. But frankly 2 things dissappointed me through above conversation, 1) The manager have to spend double time to tell me a bug 2) It seems that people still don't see the benefits of having a bug database

Not long ago I talked about how a bug database solves problems for my current company. Although I succeeded to implement it physically, I somewhat failed to implement it mentally. I wasn't happy yesterday.

The other day my manager asked me why didn't I give some tests for the job candidates. I replied: "Passing or failing the test doesn't reflect any fact about the ability to work, on the other hand, by asking the right questions, most likely you would get some clues".