Champion's slogan

1. The main slogan of champ firm is: "We are champions of the world".

Champion's knowledge

2. Champion never says: "I don't know". He knows everything. He doesn't need learning, education or self-improvement. If he admits that there is something he doesn't know, he would be soon defeated by another champion who doesn't make such mistake. Saying "I don't know" is sign of weakness, insecurity and lack of self-esteem.
3. If there is something he doesn't know, he would secretly learn basic facts about the subject and then pretend in front of the other people that he was an expert in that field for years.
4. Real champion can mess with any technology, preferably one that is the most popular and the most profitable at the moment.  Yesterday VB, today ASP, tomorrow .NET - there is nothing he cannot learn quickly and then use to promote himself. 
5. This "everybody can do anything" principle is the first thing that distinguishes champ firm from the others. If, for example, you run into an organization with the following characteristics:

• It has 6 employees and each one of them manages at least one project

• Most of the projects are solo projects or they involve one permanent employee + subcontractors

• People not involved in particular project have no idea what the project is all about

• "Everybody can do anything" principle can be easily spotted. If some project requires another human resource, the first available person is assigned to the project, without considering his knowledge of technologies needed in project. Motto that drives the decision is "He is available, so he will do the work".

• There is no coding standard, development process or documentation shared between even two employees, not to mention the whole firm. Every person works in a way that best suits him and without thinking of others.

you can be sure that you are in champ firm.

Champion's honesty

6. Words like "humility" or "honesty" don't exist in champion's vocabulary. He must use every opportunity to prove to other people that he is the best, whether they want to hear it or not. "I've been messing with HTML since 1990", "I am one of the top 10 VB developers on Brainbench", "This solution is my baby and I designed it, and now some other people take credit for it. OK, I didn't write a single line of code but that was still my idea."
7. Good champion's technique is to accuse others of his own bad habits. If champion says for somebody "He has great ego", then be assured that the ego of that champion is twice as big as the ego of the person he speaks about. Or, if he says "I despise weasels who work behind people's back" then again be assured that he has just described you his prime technique of survival in corporate world.

Champion's profile

1. Here we give you the profile of the real world-class champion:

• He "knows" all the technologies. Windows administration, AD, Exchange, SQL server, database design, XML, XSLT, VB, ASP, .NET, HTML, Perl, JavaScript - do you need more?
• Off course, he is not expert in any of these technologies. He has only learned enough phrases or buzzwords to assure other people that he is an expert in the field. When you realize that he is a fake, it is too late because he is already on your project or even worse, he manages it.
• Real champion usually does several activities in parallel but sloppily and inefficiently. He has trouble concentrating on one task and doing it properly, because he soon gets bored or realizes there is too much work to be done. He is the king of unfinished activities. The real trouble is that he doesn't see himself that way, instead he thinks of himself as of great organizer who can solve many problems at once and is superior to losers who concentrate on only one thing.
• He has never heard of any programming theory or took any programming class. Everything he knows he learned by try-and-error method and his experience. Logic, mathematics, Boolean algebra and similar words are obsolete in his eyes - who really needs that ancient stuff?
• He avoids object-oriented design and related languages (Java, C++) because these concepts are too hard for him to comprehend. He will even tell you that he hates classes. Quote: "I hate classes because they are inefficient and too complex. That's why I only use structures" or "Why are you using classes when the same functionality can be achieved by few if clauses?". You can expect even worse response if you try to talk about more sophisticated concepts, like for example, Design patterns. 
• If he is a Windows programmer, his definite language of choice is Visual Basic or VBScript
• His favourite application architecture is monolithic single-tier architecture where he puts hundreds lines of hard-readable, spaghetti code directly into form's event handlers, making of them a horrifying mix of hard-coded multiline SQL statements, business rules and user-interface actions. He hates three-tier and similar architectures because they force him to think and plan. His favourite phrase is "I do not plan, I code". Or "We gave up COM components because that damned binary compatibility caused us nothing but the trouble. We solved the problem by putting all the code in single exe file (7,5 MB at the time)." Off course, when listening to that statement you should read between the lines and translate into "I didn't have a clue what is the difference between compatibilities in VB and I didn't have time to read MSDN or to ask somebody. So I did only thing I knew."
• He types and clicks very fast so nobody standing near him can understand what is he doing.
• He evaluates other developers strictly by how fast they can produce workable code, no matter how good and maintainable that code is. He would often say: "Oh, Rob is a good guy, but man, he is sooo SLOOW!"
• To achieve that speed of coding, he uses nothing but legendary Copy-Paste method and creates new code by copying the old one. He doesn't hesitate to copy the same fragments over and over again, without pausing for even a second and thinking about better solution. On some rare occasions he creates functions or subs, but that doesn't happen so often because it is faster just to copy the code instead of thinking about the function design, parameters etc. If somebody later complains that the code is hard to maintain, it isn't the champ's concern. He doesn't have time to think what will happen to his code after he writes it or even to care about the losers who will maintain it. It's their problem they are stupid and they can't easily comprehend his masterpiece.
• Real champion also never comments his code. If he is forced to write those bloody green lines, he seeks for the first excuse to quit that unnecessary activity, usually with the explanation that he is too busy at the moment and he would do it later. Off course, later in his vocabulary means never.
• Documentation? It is for pussies, not for real programmers. Only pathetic losers need documentation to understand champion's code. Isn't it just enough to open source code? Comments? Who needs comments when the champion's code is so clear and self-explanatory?.
• Another good reason not to write documentation is that documentation can enable some other person to understand the problem and possibly replace the champion. Oh, no! That mustn't happen! Everything should be just in champ's memory, so his firm would never come to heretic idea that he is maybe dispensable and that they can live without him.

Non-champions

1. People who want to improve in their profession and emphasize quality in their work are idiots. You only need to learn as much as needed to convince other people you are the expert and the best for the job. If there is something too complex for you to comprehend, than you only have to know how to delegate it to idiot who wants to work hard. In most cases poor thing would be even grateful for allowing him to do your job.

Champions and education

1. Champion's opinion about the courses and books can be summarized in sentences like "Yes, I've been to that course but the speaker was pathetic. I had to correct him so often that everybody thought that I should have taken his place". Or, "Off course I've read this book, but there is nothing in it I didn't know before".
   If some non-champion says "Let's apply in practice what we learned during the course", champion would reply: "Well, it can be useful, but we don't have time for that right now" or "You do it, you have my full moral support. I have more important things to do." Courses and books are not very high on champion's scale of values because they don't help in building his ego or promote him, they just enhance knowledge and quality in the organization, two characteristics so irrelevant to every real champion.
2. Champion will always use the opportunity to reinvent the wheel, although everyone knows it is cheaper to use established practices or methodologies. Example: Young, enthusiastic developer comes to a champ firm and seeing the chaos in programming and management, he proposes that the firm embraces some well-known concept or methodology e.g. MSF. His champ co-worker replies: "Why should we apply other people's processes or practices? Let's invent our own process!"

Champ project management

1. Real champ starts the project, makes the big noise about it, presents himself as the project lead and the most responsible person but when it comes to real work he suddenly disappears or becomes invisible. For him the purpose of the project is to get new contacts and references, not to make a product and deliver it to customer. When champ achieves his goal, he leaves the project and goes to seek another opportunity to promote himself. The remaining dirty work is done by non-champions who either succeed in finishing the project or the project gets cancelled. Off course, if latter happens, it is exclusively their fault, not of the champion who is already on his way to screw other projects.
2. The estimation and scheduling are the disciplines that are probably the most polluted by championism. Let's quote some champ phrases in this field: "It can be done in three lines of code!", "C'mon, it takes only three hours of programming!", "I know that you need 5 days but I would make it in one afternoon", "It's peanuts!", "I have a feeling that we will deliver it on time" etc. If non-champion does the job but it took three times more than estimation given by champ, he would get typical champion's response: "You still have much to learn if you wish to finish tasks by schedule". Indirectly, behind non-champ's back: "He is slow and doesn't know much, that's why it took him so long to develop that code."
3. Resource allocation in champ firm follows the simple principle established by father of the statement "We are all champions of the world." The principle says: "If you give me more Chinese, I will finish the Great Wall sooner." So called project management experts, like F. Brooks, who claim that putting 10 people on 10 man-months project doesn't mean it would be finished in one month, are off course wrong. If project is late, engage more people, possibly at the end of the project, and you will sure make it. If that doesn't happen, blame the developers because they are lazy and incompetent. If some of them wasted time in writing documentation, expose them as the most responsible persons for project failure.
4. The word that turns on every champion is heroic programming. On the other hand, planning, resource allocation, project tracking and (god forbid) quality assurance are words more profane to champion's ears than incest or necrophilia.
5. Real champ never does planning. His main motto is "I'm sure we'll make it". Maybe there is a skeptic non-champion in the team who tries to do some math and says for example  "We have 20 days until deadline and 3 available developers. Even if we ignore Brooks Law it is impossible to finish everything in that time". When champ hears that, he knows he can't find the real argument against it, so he simply accuses non-champion that he is a pessimist, that he has attitude problem and that he doesn't believe in his or his teammates' abilities.
6. Few days before deadline, champ usually realizes to his horror that the skeptic was right. Then he uses good old weapons from champion's arsenal: rising tension in team and making everybody nervous, political motivation ("OK, we are in trouble but we can still do it, I believe in us.."), mobilization of all possible resources, overtime, working on weekends, heroic, speedy programming without reviews, quality assurance and testing etc.
7. Delivery day in champ firm usually looks like this: half an hour before deadline champions are still coding, parts of a program that seem finished are superficially tested and if application doesn't crash too much, they are considered ready for shipment. Integration of various modules produced by different developers starts at that time and naturally integration problems start to pop up. Parts of code that worked mysteriously disappear, old buggy code suddenly appears where nobody expected it, program manager suddenly realizes that some developers didn't work to his ideas and made subsystems incompatible with the whole solution. Off course, there was no written specification, not to mention code reviews or project progress tracking. Everybody is nervous, first signs of panic emerge, people are shouting and accuse each other because program doesn't work and time slips away.  
8. If by some miracle they manage to put things together and application looks like it can ship, the whole atmosphere radically changes. Champions begin to congratulate to each other, call for a drink, panic turns into euphoria, everybody is unnaturally confident and proud, as everything was great from the beginning and panic and accusations never happened. Off course, it lasts only until the customer begins to test or use the product. After huge bug list arrives, the process of accusations and responsibility delegation starts all over again. Needless to say, the blame for bad product goes primarily to non-champions and skeptics whose "bad attitude and lack of trust in team slowed us down, provoked team tensions and almost jeopardized our good reputation."

Champions and documentation

1. Real champion never writes documentation. He leaves that to pussies and bookworms who prefer to write documents and plans instead of instant committing to extreme, heroic, champion's programming.
2. His spelling and grammar are at the third grade level, because he is so busy programming and promoting himself that he doesn't have time to check what he wrote. It is so irrelevant to him that he doesn't care if he mispelles his own name. 
3. Champion is also weak in speaking foreign languages. He only cares for Visual Basic and VBScript and he leaves other languages, such as English, to non-champion rats. If somebody has trouble realizing that instead of "throw" champion really meant to write "through", it is his problem. If you don't know how to decode champ documentation, then you are probably not worthy to be part of the great champion's team.
4. If champion is by any chance forced to write documentation, mostly due to client's request, the result of his effort is usually something totally useless. When writing documentation, champions tend to prove Marx's theory of turning quantity into quality. They produce tons of documents that nobody else reads, not to mention use them as a specification for further work. The only purpose of those documents is to satisfy client needs.
   Although the champ's documentation is total waste for other members of the team, for him it is a good weapon in possible conflicts. If, for instance, later in the project some team member asks champion "Where is the specification for that?", he would calmly reply, with ironic smile on his face: "It is in the documentation I wrote. Don't you read the documentation?".