Internal Competition

Competition is healthy because it's human nature to want to be the winner. Competition is the incentive to work harder - or smarter, and to come out ahead of the other competitors.


That's useful in many areas of life. For example, in schools it drives the serious students to study a little harder, and in business it helps drive prices down and improve service.


When team work is needed, then competition between team members is almost always destructive.


This is true for families; a guaranteed recipe for a disastrous marriage is to have husband and wife compete with one another instead of working together as a team.


In the workplace, the same applies. It's counterproductive when employees see each other as people to compete against. I've worked at many places, and the less internal competition, the more efficient the business will be and more fun it is to work there.


People who are having fun at work are happy to come to work every day and to do a full day's work.


Teams members who are not in competition with each other are happy to help each other. They also have no issues about constructively criticizing each other's work and ideas. This dramatically improves throughput.


When team members compete with each other they may hide information from each other, which wastes huge amounts of time. In extreme cases they may sabotage one another's efforts. That's already destructive behavior and the business is sure to suffer.


Many things contribute to the internal competitive attitude.


Management is where it all starts. If managers compete with each other, that sets the tone company-wide.


If management creates a huge structure where everybody needs a title - and titles become important - then people will start competing with each other for the titles.


Management should channel the competitive urge towards the real competition: external competitors and potential competitors.


Project managers can help, too. The internal competition should be "everybody" against the "deadline". Pretend that the enemy is the deadline or the amount of open bugs, and create an atmosphere of "we will work as a team against the deadline".


Very often two brains are better then one; 2 sets of eyes are better then one, and having people work in ad-hoc teams doing pair-programming can achieve amazing results. If somebody always has to get the credit, then nobody will want to share.


For this reason it's best not to single out employees as "winners" or "employees of the month" unless they have done something extraordinary. It's best to cheer on the entire team as a unit; they'll gladly all go out together for a meal or a day in the sun - and this will reinforce the team spirit.


Another team-spirit killer is individual goals. People will do everything and anything to meet their personal goals, even at the expense of killing a bigger goal, like a team goal. Team-wide goals are fine as long as they do not create friction between teams.


Even between teams, you do not want unnecessary competition. QA and Engineering should be working together to create the bug-free product. Pitting one against the other achieves nothing. It's most productive when the testers and programmers can sit together; one showing how it can be broken and the other trying to fix it.


So what do you do if you absolutely feel that somebody deserves extra recognition? For example, somebody cleaned the kitchen-area and made it kosher-for-Passover?


The best thing to do is to tell them privately how much you appreciate going the extra mile. You could give them a gift certificate without any fan fare. In a healthy non-competitive environment, they will appreciate the privacy as well as the recognition.


Even when punishment is needed, or a post mortem is called for, it needs to be done at the team-level. More about that in a future post.

- Danny Schoemann

Generic - too much of a good thing?

There's a delicate balance required between making code generic on the one hand, and hard coding everything on the other hand.


Making the code generic can make it easier to tweak things.


For example, if your footer includes a copyright and the year, then you can either hard code the year, and change it every January, or you can write some code to calculate the year, or you can have the code retrieve the year from some properties file.


Here the solution seems obvious; write some code to calculate the year, and never worry about it again. However, debugging this code may be more time consuming than a yearly trivial update.


If you want to be able to control the amount of ads on each section of the page, it's easiest to control this from a properties file. Then you do not need an engineer to update the code!


This seems obvious, but not always feasible. Sometimes the ads have some business logic behind them that would require huge amounts of code to handle a generic solution.


Another problem could be error handling. Do you assume the values entered in the properties file will always be there and will always be correct? What happens if somebody enters a capital-Oh instead of a Zero? (Is this 2O or 20?)


Adding error handling has its own challenges. If the values are wrong, what values do you use? Who does the code inform and how? (You cannot show an error on the page; imagine thousand of users seeing "Bill, there's an error in the x value". Chances are that everybody but Bill will see this.)


In the mid-1990's setups went from being written in Microsoft's Setup-Basic to becoming sophisticated in order to handle the requirements of Windows-95; uninstall.


Since we created a new SKU almost daily, it made sense to create the new setup system as generically as possible.


The result was the following:

• A code base that was too big for the debugger; so we could no longer "see" what the program was doing, and finding bugs became really difficult. This was because retrieving each value from a properties file requires many lines of code, to ensure it was fail-safe.
  
  
• A properties file that was over 1,000 lines long. That's a lot of control over the minor details! But it's also impossible to control; fine tuning setups via the properties file was very tricky and error-prone.
  
  
• Since Product Management and Marketing were very creative, they demanded new twists we had not thought of. Once they would decide on a 3rd party disk we should install, another time they added a registration screen and then it would be a registration code or a "time limited" edition. Each of these great ideas required writing new generic code and adding more lines to our properties file.
  
  
• Once we had the templates for all our products, setups for similar SKU's became trivial. Adding or removing a language was easy. The engineers in certain groups took care of the own setups.

As Project Manager, I always ask the engineers to write code keeping in mind that it may be need to be changed regularly. 

• If it's something we know we want to test all the time, (like the number and placement of ads) then it should go into a properties file. 
• If it's something we will tweak once or twice (like a font size or color, and an experimental object that we want to test and either keep or discard) then it should be easy to find and easy to change. Don't make this particular object dependent on others, don't make other object depend on it - and put some comment in the code to make it easy to locate, even in 6 months time when you no longer remember the code.

This creates some balance between the joys and pains of being generic and being hard coded.

And this is another example of the advantages of having Project Managers who used to be techies.

- Danny Schoemann