Inter-component communication

The reason I call this post as inter-component communication is to differentiate with inter-process or inter-thread ones. ICC offers more flexibility and saves us from lots of implementation details (this does NOT mean not important! esp. if you want performance.). I am currently playing .Net 3.5 thus the pre-condition.

I have tried three ways of providing inter-component communication mechanisms last night as a catchup excercise on moving to .Net 3.5.

• Remoting, using FCL under System.Runtime.Remoting, via setup communication channels to allow communication cross AppDomains. Service provider and consumer could be located in same Processes or different ones over separated networkable machines. I have not had quantative measurement done but this approach gives me the fastest response. You could write all objects with functionalities you would like share in individual assembly as long as the class inheriting MarshalByRefObject. In the host app.config, you just need to set up the wellknown services in section and channels information. You could always set these up in the code - create channels and services (exposing the marshalled objects). On the client side, as long as you register the communication channels (either via .config or code), with the correct URL and type, you could GetObject from service provider side and use objects as they are local. In the latest implementation of this model, you don't need to worry about the implementation as proxy, formatter (binary or SOAP), dispatcher. You might want to use messaging to define your own version of message to contain the data passing between service provider and consumers.


• WCF, communication fundation has generate a lot of noise since the release. I wouldn't say that I am totally impressed when it comes down to performance but it certainly holds some water in the neat structure. Host WCF service provider could be either Web service host such as IIS or standard apps. WCF is to define a public available service interface, known as ServiceContract, and expose the implementation of the service via public service name (.svc file) and designated service endpoint address in section of web.config file. You can compile .svc file into two files manually using svcutil.exe as output.config (to be renamed into app.config in client apps) and client side proxy class, which offers the same OperationContract and DataContract defined in the server side. As long as the endpoint you specify in your code has been properly defined in your client app.config pointing to the correct host info and contract name, you can use the proxy just like service interface implementation on server side. To make life easier, you can add service reference in visual studio, which will achieve the similar effect, the only thing is you would not necessary what is the heck going on in the background. I guess that is the price we have to pay to be treated as dummies anyway. A WCF service transport protocols as TCP, UDP, MSMQ or SOAP. It could also use security protocol in the service bindings which is a real bonus, see here is a good article describing security issue in WCF! And if you are really interested, go write your own binding, channel and everything else. There are tons of references available. Service Configuration Editor is a good tool supplied by MS to configure the service.


• Webservice, using clases under System.Web.Services, we could expose the service via standard web service provider hosting in web servers such as IIS. Officially the bandwidth and all other performance will be bottlenecked by IIS but this is another topic out of the scope of this post. You can implement any services (inheriting System.Web.Services.WebService class) to be exposed, with [WebMethod] attribute tagging operations you want other people to access. .asmx has the similar markup content as .svc mentioned in WCF. Although this approach a lot of work will need to be done during deployment the web service part, there is not much for you to configure other than focus on implementing the service itself. However, the price you paid here is this is the slowest method, because you have given up many of your controls to web service host Scheduling. To use this service in client side, again you could either go with manual route using wsdl.exe to compile wsdl (.asmx file). This will give you the proxy class with exact the same name to be used in client side. Or you can go the lasy route adding service reference which will give you soap(ed)client as proxy.

One thing needs a bit clarification is that there are many ways to host the service provider in all of the amentioned three different approaches. Web service host such as IIS (do not confuse with name Webservice, if you could ;)), standard console or application host, Windows service host. Effectively, any application models which are capable of listening to client service request could become host. All these approaches could be used to implement P&S and multi-casting patterns one way or another by specifying either the contract attributes or hooking up to the same endpoint/url.

A flexible configuration framework

I am currently designing a system which by default will be interacting with many software, hardware components, some supplied by various third parties. One of the common pitfall for system of this kind is people tend to ignore, or at least do not pay enough attention to, the challenge presented by the system configuration, formally referred as deployment.

I am not discussing configuration in the sense of setting system parameters, configure program environment as such. Dealing with a middle or large size of system, first thing I learnt is not to focus on each individual component (from design phase) and never make assumption how people would like to connect their cables (or setup their wireless links). System configuration has been mostly pushed to the front line and in many organisations it to a degree became a de-facto FAE (field application engineering) function. On one hand experienced FAE engineers becomes a rare race; on the other hand, many of them do not really have sufficient visibility of the system capability supplied and configured by themselves. Deployment of such system became a lengthy and painful process between the customer, distributor or integrator, and of course (engineers within) the organisation.

We have put a lot of thoughts in designing one of our new product, trying to find a most intuitive way for people to deploy the system. They only need to know what they want to know about what they are doing. The overall presentation of configuration UI for such system will be a Zoomable diagram. System needs to define and group certain entities at different layers. Join and leave group will be default supported functionalities for an individual entity at that level. Multicast could be enabled and disabled in the group. Entities within group could also be addressable. Each group is governed by group policy, which will be applied on top of the entity policy. Each entity has defined interfaces (communication interface, supported inter-entity communication channels). Entity is a logically self-sufficient unity and GUI is NOT an entity. All interfaces are configurable and expose the same configuration interface, of course with different property implementation. Similar to the /proc/ concept in Linux, each running entity will create a dynamic symbolic link, to which read and write could be enabled to dynamically change entity behavior and this will allow embedded script engine to be possible in the future as well. Wizard alike step by step system configuration is used to provide clear and un-ambiguous options at each level. The key point is the wizard will be triggered at each level with different content. Drag & drop toolbox will dynamically reflect the selectable and configurable entities could be contained by current Entity-of-focus. To integrate with third party devices, a generic wrapper interface is to be implemented for each of them. It could as as simple as to pass command and retrieve status; it could also be as complicated as to implement a functional agent to interfere the logic. At last, but definitely the least, the multi-level hierarchy will be serialised into XML file and could be reloaded and edit anytime in the future.

All about estimate

When we do not know what is gonna happen, we panic; sometimes in order not to be completely acting like elementary organisms, we guess.

In essence, we will not possibly know what is like in the future (if we do, there won't be one). A project is a means to explore certain unknown and provide solution consequently. Sometimes we succeeded, other times we lose miserably. To succeed in a project, there are hundreds of things must go right, out of which, the estimate. It might be too convenient to generalise the action we take when confronting with unknown as estimating. By doing so, however, we could possibly take a peek at where and how estimate comes from and what should we do about it and how should we use it to help us.

As being said, we cast our conjecture or theory on things we do not know for sure and then hope the dice would be hit, with bit of luck. Making an estimate is just as difficult as doing the work itself, if not much more. When there is a problem, based on analysis of the problem itself, past experience, consultancy advice, we offer our best guess. One thing people do realise and start to put more and more focus on is the approach with which the estimate is made, i.e. with the same information, how do we estimate something is probably going to happen - probability of the estimate or simply saying, treating estimate as a function of multiple random variables. Scientifically, techniques such as three-point estimate not only give us the range of estimate but also provide the confidence level associated. Although there is a fundamental flaw in such method is the assumption of independence of variables normally doesn't apply. Anyway, the estimation approach is not what I am going to talk about here, although I have already used half of the space...

Can we estimate? If positive, why do we need? If we do need, how do we use it? If we do know how to use it, how much confidence we have with it? What happen if it goes miles wrong? Do we need to update it with newest information? What does it mean by hitting the budget and endless of delay? (This question ladder should really start from another "do we need an estimate?" but as we all know that normally being answered straightaway as positive.)

Yes, I think we can and have to estimate, otherwise walking in a mist is not going to help anyone, especially those who hold they hands and await for the return of their money. Everything kicks off and depends on the esitmate, believe it or not, no matter engineering or manufacturing, purchasing or selling.

We need estimate to plan for the unknown, what should happen is that most of our plans should go from paper to bin very quickly. We need estimate to decide actions. We use estimate to de-/convince people and persuade resource and investment of interests to the good side of our belief.

The confidence level of an estimate depends on the source of the estimate as much as the approach we took to achieve it. Estimate should never be A number. You have already put everything you have on the edge and tipping your toe into a gambling game if you do. Confidence of an estimate is more important than the estimate itself, as suggested by Entropy theory. In the unfortunate but most likely situation, things didn't go as planned, (which is one of the main reasons estimate is defeated, assuming people know how to estimate.) the last thing we need is being pessimistic and throw the baby away with the bath water. Looking at whether it does fall in the possibility range you had and what is the thing really happened and triggered the domino. To find the root cause of effects would be most likely helping us get back to the game - by updating the estimate and re-do the homework, when I say homework, I mean it, on daily basis. It is also not extreme that some cases this happens on hourly basis.

Hitting the budget is always a nice thing to have. In common sense, hitting a budget mostly means management is doing a good job in planning and managing. To me, hitting a budget doesn't means you get on the train at the last minute just before the conductor closes the door. The reason why I say it is that hitting budget itself is actually funcationally irrelevant. A project is about capability and experience (in financial terms) dealing with unexpected events. A budget is made trying to measure the degree of unexpected events. It has fundamental means to play with while in nature random. Sometime if hitting budget as a target overrules logic thinking and long term view in decision making pivot, it will pay for itself in an ironical way. If you hear people complaining about the endless delay of a project compared against its original estimate, be careful, firstly you should probably ask is how the estimate gets made and when it was the last time we update the estimate. Finally, my killing question - Is there any change of scope to what we have been estimating against?

Requirement and knock out feature

Requirement is what makes things happen. It comes from needs to satisfy various living or working condition, more importantly however not intuitive, to satisfy curiosity and the hunger for invention.

In a product development cycle, everything starts from requirement. The first misconception stands out from here - things start from somewhere, so we must know where it is. We make a lot of assumptions about what we know, what people want, what we donot know, what people donot want. Yes, unfortunately, most of us start from 'we'. I think it is inevitable. This is how our brain works - when it comes across new problems, new stimuli, it first of all is to search the potential resonance. During this stage, learning and extraction following by inference happens. Any requirement analysis approaches fail to respect this are likely to be doomed.

Traditional practitioners believed this planet is the centre of the universe. On that thread, they had this fantasy either the designers are fully aware of what is required from their past lives or they are just genius, just know it. After many pioneers hit their heads on the wall, with only handful of them hit the dice, we finally decide to collect and analyse requirements. Now is the era of believers. People have this naïve belief in customers, or who would buy the thing we are gonna build. Tons of man hours, lots of support to airline economy didn't seem to pay off - this gap between what customers are satisfied at and what has been delivered is like a haunting ghost, never go away. Most of the products have to have sufficient investment to sustain till we 'finally' hit somewhere in between, or better than competition, or customers do not really have much choice. Surely there are still many very successful products coming out from the bottom of these waterfalls. Many products of this kind took long time with concentrated resource and reasonably static market environment.
Steadily, we started to realise that customer is NOT our mentor, he doesn't know what we assumed he does, hoping by doing that our development lives would be easier. As matter of fact, customer doesn't have clear view of what he is asking for, only knowing there is something alike to meet his needs. Even further, sometime customer doesn't know what he really needs. As I have explained in previous blog, he thought he wants XYZ, in fact all he wants is to achieve ABC, and he think by XYZ he could make it happen. As product development go along, the requirement creeps. This is natural since the better visibility of the product, people who look at it would have more information to feed their brain and that would either trigger a verification process, or a inventive process will be triggered to re-shape and enrich original fluffy fuzzy needs. With all these cruel realities being exposed on the floor, alongside the acceleration of market changing speed, we have to look for alternatives.

One thing also worth mentioning is, no matter what, there is always a conceptual understanding that product is delayed, in fact, what is important is managing the expectation. By the way, with second law of thermodynamics, you can not win; you can not break even; you can never get out of the game.

I don't know exactly what to do, but these are what I believe should be happening within a success,

» Customer is God. This is a correct statement only within appropriate context. Product development team should lead customer to find out about their real needs. Hence customer is not just paying for the end product, but also the learning process and experience. This would make sense for our accountants whose only interest seems to be costs and benefits (to be fair, we all do).

» There is no way anyone can envisage hence plan all out in advance. Even there is a small fraction of possibility, that would also decreased in a significantly non-linear manner to the degree of complexity and speed of change.

» What we can do is be honest with ourselves and plan out what our eyes can see in front of us. In the same time, knowing how to use the back of envelope estimate as a guidance rather than a full time project manager's job to cook a good-looking chart.

» Commitment is a serious business. Without a feeling of fixture doesn't mean no commitment needs to be made. Be aware that every step you make in product development, every deliverable coming out from the circular pipe would have directional effects on what is going to happen in the next ones.

» Break the cost, time, quality triangle. Define the affordable time and cost then see what we can deliver.

Knock out features are those hit the invention button, not only because they have been implemented by genius who is capable of peeking the wonderful requirement myth above, but also the designer is consciously delivering altruism - probing the user's curiosity, allowing them to explore more with this product rather than less. The reason that I say this is I believe every product, every new gadget in a way limited your option, you view of the world while it offers you certain ability from the vehicle. When we say a product is intuitive, what we are really saying is the product doesn't limit the way we look,feel and deal with things by what it offers. Just like dad used to say, "you can go ski, as long as you put on those clumsy clothes" or "you can use a blackberry, as long as you can live with tiny keyboard hurt your hands".

Handson or handsoff

This comes up from a conversation with Jonanthan. Although it is possibly one of the first questions I have to consider when first transition from engineer to technical management. Bottom line is I don't believe effective management could be achieved without solid understanding of technical difficulties and product itself. Sounds like an easy call?

PMI tells us, 90% of project management is about communication. What PMI or most of the management books did not tell us is, both management and engineering are certain types of data processing. Engineers process data via either physical transformation (mechanical gear transmission design, servo control, encoder sensor feedback analysis), electronic signal process (signal generation, data sampling, signal analysis and feature extraction, spectrum analysis and estimation) or logic interpretation (logic circuit design, time-based state machine, bus-based data propagation and transmission, protocol interfacing, optimisation algorithm, pattern extraction and construction, data re-organisation, logic mapping and pattern classification).
What managers do? Not being funny, unfortunately, this question gets asked often by engineers! Many managers choose to hide behind of their roles to 'follow the process, do the job' rather than really thinking about what should be the management responsibility, focus, and what gets things done.
In my opinion, management is also about processing data - processing data collected from 'sensors', data analysis from systems (could be bad data, or even to extract useful information from noisy data samples), data feature extraction and inference, data propagation and transmission, protocol interfacing, pattern recognition and estimation, most importantly data generation. I will break these down:

• Data collection - Managers are responsible to put the right and sufficient information together, either product issues, engineering design constraints, requirement specification, cost etc. The method to collect the data has to be scientific. Unsound approach will invalidate the data you sampled, pretty much the same way Jury will look at your case.
• Data analysis - Managers are also responsible to analyse the data collected. To know what we are looking for, and what we can look for, what pre-processing is needed before data really makes sense to us, do NOT jump to conclusion before data is actually understandable. Gut feeling is irrelevant.
• Feature extraction and inference - Now managers with cozy office will need to do some homework. To extract the features embedded in pre-processed data is not an easy job. You have to be sharp enough to not be buried by trillions of bytes flushing in front of your eyes every milli-second (slightly exaggeration here...).
• Pattern recognition and estimation - To recognise patterns certainly needs experience, although in lots of movies directors trying to convince us it is all about gift.
• Data propagation and transmission - Interestingly, this part is what most manager do well, exceptionally well, to the point in many organisations, there are many managers they believe, or at least it appears to be, that the sole purpose to have management role is to be an information passenger. In fact, to make sure the data is propagated to the right receiver and that only needs a lot of skills. You can't use broadcast everytime without getting in danger of damaging enviroment; multicasting needs policy support; unicast incur transmission overhead.
• Protocol interfacing - Almost every product, to be a piece of usable item in real world, it has to interface with other parties, like it or not. Data transmission, or in a more explicit term - communication, must follow certain protocol to be able to achieve efficiency, security, stability and robustness, extendibility and integratability (oops, sorry, too many abilities...).
• Data generation - Most importantly, as much as a general rule, to produce data, is what really matters. Without this, there is no need for processing, and bluntly, no need for management. Management is about decision, is about getting through all the steps and being able to, and willing to, make the decision about whatever it is about.

Without too much efforts (actually, a bit, admittedly), I am convinced that whether you are doing engineering work or management work, you are processing the data either way. The point is the real difference in handson and handsoff is not what work you do, is about how you do it. Handson is about you get into the details about what you do, being realistic and objective about the true identity of the data, do not randomly or arbitrately interpret the data samples, being scientific about the embedded patterns and using which to make prediction or logic inference. Being handson is about choosing right methods and attitude to process the data, to confront with real world issues without unsound assumptions, being honest about situation and problems, and a little bit of faith in problem solving (this is in fact belief in finding resonance with the underneath patterns embedded in the universe, I am a great believer that we donot create patterns, we find and learn them).

Although in reality, handsoff engineering might sound a pretty crapy idea and one would get caught easily if he keeps his handsoff while he was supposed to deliver 5000 lines of code a week - let's just say being a manager, keeping handsoff will be less vulnerable in the short term compared with engineering work. However, to an organisation, handsoff management will have much more detrimental long term effects.

Script engine in .Net

Embedded script engine in applications which require significant level of customisation is a very attractive idea. More than that, the script based component actually makes the component level deployment possible, a different implementation to plug-in structure. One thing to look out for is surely performance.

1. CS-Script is claimed to support on .NET1.1/2.0/3.0/3.5 versions of CLR implementation with limited support on Mono. It effectively creates the support for CLR code compilation. You have accesses to all the libraries supplied from .Net. With the use of configuration file for scripts, you could really extend your application functionalities. In addition, you can take advantage of other CLR compilers (by instantiating System.CodeDom.Compiler.ICodeCompiler interface) and Config console. Referring to namespace would be able to access your own object model. One good thing is that with CS-Script, you can compile any scripts into standalone executable.
   
2. Prior to .Net 3.5, namespace Microsoft.Vsa offers the built-in scripting capability. Vsa really is a .Net version of VBA. You create your own instance of engines from Microsoft.Vsa.IVsaSite interface, from which you can implement your engine to accommodate VB script, Java script and C# script engine. An easy tutorial can be found at here. You could expose your object model within your application to be reused from scripts later on as well.
3. Good old days - Microsoft Script Control used in managed project. Again, you can expose your own class model via this. You would need to instantiate an instance from MSScriptControl.ScriptControlClass and then select the script engine for either VBScript of JavaScript (of course MS version of JS). This article has introduce an interesting way of scripting asynchronous call.
4. There are a few other script engines projects available as well. Google will take you there I am sure. I will not go on here.

Be aware the difference with Windows Script Interface. WSH enables Windows OS to run scripts in a way extending batch file. By default Windows will interpret JS and VBS files, with WSF you should be able to have a sense of language independent OS scripting. Although WSI has been deprecated since .Net 3.5. You could even create script COM objects using Window Script Component. However, Windows Script allows you to script capability at OS level. If you imagine Windows as AN application (well, not the best one shall we say), and Windows Script provides a way to Script this application.

Backlog and throw your project plan away

-- reflection on Mike Cottmeyer's Agile presentation

Assumption on requirement is evil.

Backlog: As a ___, I would like to do ___ to achieve ___. The reason I highlighted this note is this is so damn true. Once I had a complaint from a customer in Italy threatening to kick our half million pounds system out - he is not satisfied. But why? He said he can't do XYZ. Okay, everybody in the loop starts to panic that why our system can't do XYZ, to do that, how long they have to wait for etc etc. Then I called him up and say hey, can I just ask one question, why would you want to do XYZ with our system? He said, "because I need to be able to have this ABC effect." I don't have to complete the rest of the story I guess.

Reverse the triangle - define time, cost first rather than scope.

Release planning is to follow the defined time, affordable cost and see what we can achieve from the backlogs (with MoSCoW applied split in backlog sets).

Short cycle time to be fixed first and then we can look at what could be done for that time. The planning efforts should not be focused on the nice good-looking Gannt chart, but on the defined Releases->Sprints, with the negotiation of backlogs in between.

SOA

"Simple, clear, purpose and principles give rise to complex and intelligent behavior. Complex rules and regulations give rise to simple and stupid behavior." -- Dee Hock

Project management legend

Every morning you woke up and google for project management you will find new books, blogs, podcast talking about new thinking or methodology. I have spent 45 minutes in the morning on a train to a place where I burn myself to full extent everyday. I am loving it. Not because any project management legend reveal itself in my daily work, on the contrary, none of them has.

Here is a suggestion, go to your bookshelf and your harddrive, pull out all the content which are project management related, put them in those big PC box you took for free from office. The idea is, let's see what would happen if you don't refer to them for 3 months.

I never believe, you can adopt a project management methodology and make it work. It doesn't work like that, the sequence is wrong. You deal with mess for a while; because you are a hitchhiker in nature so you are lucky that you have not got bogged down by the negative experience; you decide that changes might sound like a good idea; you think hard about which are the areas should be improved, most of the times, those are the areas are most sensitive in an organisation; you work out what is wrong, and what is the result should be if thing doesn't go wrong; you maybe don't know about the fancy buzz words used in various ridiculously expensive management training course, but again, you are lucky enough to know some common senses - what stops things working is bad, what makes things tick is good; you then put those small pieces which made things tick from your past lives and those you stole from greater minds; now you have weapons to deal with the devil which dragged you down; you exercise them, some are still tasty, some gone out of date already, anyway, you end up with bunch of practice which proved to tick the boxes in where you are... This is for real, real management life.

So, why we choose to escape from the problems and wish that someone else who is NOT in your position has already figured this all out FOR you? There is NO free lunch. No one has come along from exactly the same path. If you are a project manager in an organisation, you should consider yourself unique, although wiser did say that you can't believe how much effort people has thrown just try to be normal. The problem is unique, the opportunity is unique. No one has resolved this before, there is no place to hide for you.

A good project manager don't believe in legend or myth. He has faith in humanity. We know what went wrong, as long as you keep a fresh eye in the morning; we also know how to deal with them, as long as we have enough courage not to search for legends.

Now, it doesn't mean that we could not summarise typical situations a project manager could end up with.

A. Endless project

B. Fragmental project team

C. No focus, no confidence, no commitment, if there are identifiable stakeholders

D. Faultlessly wrong design

E. Time/Money/Quality pick-two game

F. Now really, we don't know what we are building, we aren't even know who is going to buy the stuff

G. For the name of heaven, there is no safe island, all you have is risk, how could you manage

H. On top of all, let's play politics

A good project manager has fairy good idea of what kinda troubles he has got himself into within very short time. Sadly, many of us make assumptions way too easily that we could rely on our shiny experience to kill the bugs. Unfortunately, history proves us wrong, all the time actually. Experience tells us what problems we might need to confront, but it doesn't offer us a silver bullet. Simply becase the solution of the problem is so unique to the subtly different environment you are in. Let's just say, give up on the reference thing, be creative, no one is gonna blame you that you didn't quote the Greece as long as you get people out of trouble.

Doing a good job or being a good soldier

It won't be new for most of us in your career there is a time you will be thinking whether I should do a good job or just be a good soldier - do what I am told.

Things aren't that straightforward I am afraid.

We all have free will (actually, this might be the reason why most of us spend most of our lives moaning about most of the things). Hence everyone of us has a different view of even the same matter, not mention people at different roles will take their interests at different places. Managers are generally not interested in what you are doing, I mean it. It is not because managers don't care about what you do, it is they can't. A good manage knows how to keep productivity (by providing necessary equipment, pressing the motivation button, getting rid of whatever it is in the way, etc). So if next time your manager comes to you to chat about how much they care about you as a person. Take it in this way:

First, he respects you and value what you do for the team.

Second, you are not friends, he is trying to find out whether your productivity is maintained or not and what he could help if otherwise.

Coming back to the dilemma, it is quite easy to get to the situation that you believe you know what is the 'best' route to get the result while your boss is just acting like an asshole. You come back home and complain to your wife, "why the heck my bosses are always stupid assholes". Admit it, we all do. However, if you calm down and think it over, you will find out that there is no such thing as right or wrong - your boss has his view, his priority, his take on the matter, his weighting algorithm on things. What appears to you as a big deal might be just a pawn on his chess board after all. What you think is a trivial bug and not even worth to be fixed in next release might be the biggest complained point of the product. Guess what, as long as you and him are different person, different role, this will manifest itself everywhere in the Universe. So stop being disrespectful to your boss' mum and start to find the best way to communicate what your take from your point of view, meantime, try to consider, or just ask, about your boss' other balls in his court to see whether you have missed something. Let's be honest here, your boss might be also scream in his mind thinking about what the fuck are you doing. This might be a good step forward for your relationship.

Above we assumed that you have taken the positive approach. Yes, you hear it right, positive approach. Moaning and yelling is positive! Trust me! If you do, you are still trying to do a good job. Just be careful, many cells of us like to use this as an excuse that "you know what, I am angry because I care; I am frustrated because I have come across so many obstacles, I care a lot about this business". This is bullshit, totally bullshit. If one really cares, he doesn't just talk and moan, he takes a step further, getting things done.

Okay, now we have Mr. Negativity.

"I will do what I was told, only I was told. Guess what, I am not responsible if problem happened, I already said this is not gonna work..." This is one of the most typical responses you would get. To clarify, there are two groups of people here. Some of them actually think there is a better way, and the problem is in their boss. Basically they believe the ability of their boss hinges the success. Although we all know that is not true. I believe some people are bosses for a reason, a good one, generally they have some capabilities you don't have, it is not one of those lucky number things. If one really believes probability, one should know luck doesn't exist. Anyhow, this group of Mr. Negativity decides the easiest way is to be a good soldier, well, maybe just a soldier, to the hell with being good.

This is no worse than the second group of Mr. Negativity, my opinion. There are people who really know how to take advantage of disconsent or opportunities of disagreeing. They don't know what a better way would be, they don't have another suggestion, they don't even have an opinion. No, that's not totally true, they do have an opinion - to use disagreement as guise to not having one. I guess it is quite obvious right now that this is not my favorite type of situation. To quote Prison Break, these are people who really are sufferring in the "capativity of negativity". My suggestion to this is, if you don't think you can change them, get rid of them, ASAP, before they jepodise the rest of your good crops.

How to find the best people

First of all let me clarify, I am not recruitment consultant or anything on that vein. So, this is not professional advice as such.

Sometimes is tricky during the interview process of how to keep the consistence. In large organisation people tend to rely on the established process which is more or less based on how to carry on an interview process to candidates by those who are taking the similar roles in the company. However, after being interviewee and interviewers for many years, here is the conclusion I have got so far, interview is only as good as the interviewer.

The reason why I say this is that believe it or not, if you are an interviewee, you need lots of luck to make the day yours. Many things could affect how the interviewer judge your performance of that day. Many organisations believe they can tell the quality of the people within a condensed period of time to poke every aspect of the individual. I think it is scientific sound. However, in reality, the chemistry between the interviewer and interviewee is all that matters. I might have exaggerate the effect of this. But I think only if we recognise how much our feeling can affect our decision on people, we could then be able to try to control the feeling from making the right decision.

Here are some simple rules I have learnt, and I am sure some of them your found familiar somewhere else, kudos to those presented the similar ideas:

People donot change that much

You will not change too

People are different

The best people tend to stick to the same type

How to tell if you are talking to someone who has the quality to be shine in your organisation? The assumption I made here is he or she at least doesnt fail miserably in any of the questions with binary answers. Most of the simple criteria I used are easy to tell.

1. He or she has something to gain from this organisation, what ever it is, money, job satisfaction, technology geek, challenge etc. On this topic, being a idealist myself, I never believed one can shine if all he wants is money. However, big bucks always helps!

2. He or she has something to contribute. If he or she feels useless or incompetent in the coming work, you might as well help yourself not to put other people in misery.

3. Is he or she different?

4. Has he or she been making decisions of his or her own?

5. Is there a spark in the eye? Superficial huh? If someone walks in and you feel he doesnt have confidence in his eye or he couldnot focus or he just donot know what to look at, you need to be careful.

6. Do you like him? I just said you should control your feeling. BUT, your gut feeling about the candidate is telling you something you could not be able to get from logic.

7. Are you trying to find something which you cannt achieve in him or her? If you are, donot be.