IT common role anti-patterns

Text of this article is a quote from An Agile New Year's Resolution for All of Us by Scott W. Ambler, Dr. Dobb's Portal, December 15, 2006:

I think that if you spend a few moments to reflect, that you'll agree with me that you've seen, if not exhibited yourself, one or more of these common role anti-patterns:

• True Believer. Also known as the "Born Again Developer," a True Believer "just knows" that their preferred approach to development is the best one and is very happy to let everyone else know it. The True Believer rarely seems to question what they know to be right, and strangely enough often struggles to justify why it's right. A better approach is to be open-minded but skeptical at the same time, recognizing that no approach is perfect and can always be improved upon.
• Mind Reader. In the middle of a discussion a Mind Reader will state what someone else must obviously be thinking. Strangely, Mind Readers only seem to pick up on negative ideas, or at least ideas which very clearly cast the other person in a bad light. A better approach is to ask other people what they're thinking instead of guessing; in other words, actively seek to communicate with one another.
• Hypocritical Preacher. A Hypocritical Preacher says one thing yet in practice does something else. For example, it's very easy to preach about the virtues of open and honest communication, or to promote collaboration with and respect for others, but it's a completely different matter to discuss ideas with those same people when their ideas are very different from your own. It's also very easy to preach about quality, yet not so easy to fund, develop and then support an automated, end-to-end testing environment. The solution is to practice what you preach, and if you're going to preach to only do so about the things that you actually practice.
• The Spammer. Need I say more?
• Unjustified Criticizer. An Unjustified Criticizer will often criticize something without having read it, often because it's about a topic which goes against their true beliefs or because it's written by someone they have disagreed with in the past. Unjustified Criticizers are easy to identify because they provide insufficient arguments to support their criticism, in fact they often make blanket statements and then refuse to justify those statements, and rarely seem willing to share their actual experiences pertaining to the topic (usually because they have none to share). The solution is to describe your own relevant experiences and then ask them to comment on them. You might not get an answer, but at least you'll provide others with a viewpoint based on fact.
• List Dictator. List Dictators are often Hypocritical Preachers, True Believers, and/or Unjustified Criticizers who find themselves in a position of power. A List Dictator will often define exactly what can and cannot be discussed on the list, but will often choose to flaunt those rules themselves as they see fit. In the extreme, List Dictators will often ban people who they feel are dissidents instead of publicly addressing their issues in the discussion forum. By limiting the discussion, List Dictators attempt to prevent others in a discussion forum from questioning the dogma which the List Dictator wishes to focus on, thereby promoting their agenda. To be fair, one benefit provided by List Dictators is that they often thwart the effort of spammers. Unfortunately there's little that we can do about List Dictators other than to try to convince them to behave more responsibly, otherwise we need to vote with our feet and create better discussion forums.
• Unknown Poster. Unknown Posters typically have list names such as "Cyber Guy", "Agile Guru-Dude", or "Object-Data Architect". Cute nicknames, if you're a teenager living in your parent's basement, but they don't tell us who you are. Unknown Posters often seem to be True Believers who don't to have the courage to be associated with the ideas that they're espousing. The rest of us reveal who we are, and we should invite everyone within a discussion forum to do the same.
• Indifferent Specialist. An Indifferent Specialist is someone who is often very good at what they do, be it Java programming, business analysis, or database design, yet they are rarely motivated to learn about things outside of their specialty. These people often underestimate the importance of these other things and in extreme cases will choose to denigrate these topics or the people who believe in them. Statements such as "Oh, that's something the programmers do" or "We need to blame management for that, they can be so dense sometimes" are indications that someone is an Indifferent Specialist. The solution is to strive to become a generalizing specialist, someone with one or more specialties and a general knowledge of IT and the business domain that they work in.
• Backstabber. A Backstabber will criticize someone, or their ideas, but their victim doesn't know that it's happened because they weren't included in the conversation. The solution is to have the courage to involve the person that you're criticizing in the conversation so that they have an opportunity to respond: In the case of online discussion forums, explicitly copy the person on your posting if you're not sure that they're on the list. If you have a strong argument, then you shouldn't be afraid of a response, should you?
• Blamer. Blamers are often Indifferent Specialists or True Believers who are a bit too arrogant for their own good. Instead of accepting responsibility for trying to solve a problem, they instead choose to blame others for the problems. Agile teams work together collaboratively and take responsibility for the project as a whole. If there's a problem, or if something isn't working well, it our responsibility. Blamers will promote division within teams, and in discussion forums, often to promote their own political agenda. The solution is to point out that we're all in this together and need to find a solution to the challenges that we face, and not to just push them off to someone else.

Time Management

Time Management is a principal subject when someone talks about planning personal activities in the most efficient way. But, unfortunately, this topic is often being omitted when focusing on the management in general.

Isn't it a manager's responsibility to build her/his team work in effective manner?

It's not about creating 15-minutes detailed work plans for an each team member (I bet anyone can do it good enough even having only 2-3 subordinates). But, at least, a manager must help his team to understand what is expected, when, and how to accomplish it on time.

However, we've used to see the opposite in real life... Instead of helping employees to plan their tasks, to follow that plan, and to update it when required; their bosses help them to ruin their personal time management process. It's being done by forwarding unsorted tasks, by urgent report requests, by unplanned meetings, etc.


If you are a manager and want to have your team working effectively, it makes a sense to consider the following rules:

• Set realistic deadlines based on the date when you really need to get the result, not just to make your team being in rush;
  
• Do not schedule urgent meetings if it's not really required. Give your people some time to adjust their plans;
• If you have to assign several tasks to an employee, make sure that you set the priorities.

Change-Driven Development. Introduction

Have you ever taken part in a project, that wasn't affected by some extraneous factors being changed during the development? Probably not, if we do not consider paltry projects-tasks that take only few days from defining initial requirements till a final release. In every other case, regular changes are just a usual part of software development process in modern world.

However, despite the regularity of such changes, teams often turn out to be incapable of responding to new, clarified or updated external factors in time. As result, it leads to frustration of deadlines, and to trite excuses like: "it wasn't possible to meet the deadline because the customer was changing their requirements continuously" or "an extra month is required for new developer to gen up on the project". Familiar cliché? In many cases, these explanations are fair and they do really explain the reason of the failure. Alas, opening the reason just helps to smooth the situation, but not to solve the original problem, - developing the product on time and budget. The same way as it doesn't help to consolidate company professional reputation.

Realizing inevitability of changes, many companies already applied some management processes regulating a set of actions that need to be performed in a case of particular change events. Some other companies went event further, and introduced concepts to control risk of rising one or another specified change. But in spite of these precautions, factors that seem minor accumulate and finally influence the course of whole project, and essential events are often found to be amiss.

In some future posts, I'll describe an idea of adapting existing development processes in a way that is based on change perception as a natural factor settling a project flow - Change-Driven Development. Described method is admissible for most existing development processes. Simplicity of implementation and adaptation appreciably facilitates acceptance by team members. The result of application is achieving commercial project goals in the shortest term, at the same time, keeping the climate easy-tempered and stable. For its turn, the last does even more - it decreases turnover.

Vain Meetings

All company meetings can be characterized by their goal:

1. To exchange some information (e.g. status meetings, reporting meetings).
   
2. To discuss some issue(s) and come to decision.
3. To comment something that happened or is going to happen.
   

I've ordered these three goals by their popularity (most frequent goal is the first). But the same order is also valid for percentage of useless meetings (highest percent goes first).


Common important thing for all kinds of meetings is the audience. Missing some required person or having someone, who is not involved into the subject, significantly reduces effectiveness and sometimes becomes complete waste of time.


But let's continue talking only about the 1st kind of meetings, because they "kill" much more valuable time than all others together.


The reason is quite simple. We are so used to such information exchange meetings, so almost nobody tries to think if particular meeting is really required, but just schedules it...


There is a short questionnaire that can help you to identify problems related to particular information exchange and decision making meetings:

• Is there enough information to create meeting followup letter?

Nothing to say about the meeting results? Probably, the meeting was completely useless...

• Is it possible to divide followup items in groups by people involved in an each particular issue? One person can be in one group only.
  

Do we have two or more groups? If so, it would be better to divide the meeting in smaller parts with reduced audience.

• (related to the question above) Do we have a group or groups of one participant only?
  

If so, then there was no need to invite these participants to the meeting. It would save their own and other's time.


Well, it seems like I've gone too far... Of course, information exchange meetings are still required and important:

1. People, who works in the same area, need time to communicate together. Status meetings fit this purpose until most participants really communicate there. If not, then the meetings are too often, or there are too many participants.
2. Reporting meeting are useful both for upper management and for colleagues to observe progress results. But if people becomes sleepy, then either meetings are too often (there is nothing new each time) or too long (there are a lot of unnecessary details).

Reporting, Discipline, and Motivation

Did you ever created a report, or asked for a report from your subordinates? It could be a problem report, regular status or progress report, or any other kind of summarized information.

Some reports are very useful, others are just waste of time.

A lot of bosses are sure that reporting is helpful to maintain discipline. True, until the person who prepares the report realizes that this information is really useful for someone (even for herself/himself). Boring and useless work is one of the strongest demotivating factors!

There is no need to look for a compromise between discipline and motivation. You can have them both in your team!


Useful reports

To get a good report, first of all, it's required to understand why this report is needed, and how it's going to be used.


Samples of bad reasons:

• just to have this report;
• to have something to read;
• to make someone thinking that she/he is under the control.

Samples of good reasons:

• to check how results correlate with the plan => to make adjustments if required;
  
• to analyze possible reasons of the problem => to fix the problem and adjust the process for future;
• to get more details in particular subject => to make a decision;
• to combine separate parts into a large picture => to make adjustments in a global plan or to report upper for even more global analysis.
  

As you can see, all good reasons assume further use of that information. It's simple, isn't it?

Code Review vs. Code Inspection

Can we skip code inspection process?

In his novel, The Deadline, Tom DeMarco gives an interesting sample about reducing project development time by removing verification stage from the development process. Well, I'm sure it's possible for an excellent team, but unfortunately it's still too extreme for most of project teams in the real world.

However, code inspection process is a bit different thing.

Can you imaging that experienced developer, who always created exemplary code, will start working in a slapdash manner? Yes, if that person has some personal problems, is bored by the project, has a conflict with another team member, or the like. But it's all about management, not about programming.

Professionals, who keep working in the same area, won't lose their knowledge and experience! Thus, there is no need to continue inspecting project code if several recent reviews confirmed that the code is in good condition. It's just waste of time, nothing more.


Code Review vs. Code Inspection?

It's a common thing, to mix Code Review and Code Inspection terms. However, these two process have different goals. While Code Inspection is focused on verification that source code corresponds to coding rules, guidelines, and has no obvious smells; Code Review helps finding defects and creating a base for code refactoring.

Most areas of code inspection process can be automated (e.g. Static code analysis). Code review can not. In fact, this is a cornerstone of code reviews - using a human brain to read and understand the code, looking for defects with a fresh eye. Peer code reviews remain the best approach for finding code defects (Sergei Sokolov. Bulletproofing C++ Code. Dr. Dobb’s Portal, January 09, 2006).

On average, 60 percent of defects can be removed via code reviews (Barry Boehm, Victor R. Basili. Software Defect Reduction Top 10 List. CeBASE, January 2001), so it's really helpful to introduce regular code review process when the code is being actively created.

500% productivity increase

Recently, I received an invitation to a Users' Conference that was dedicated to one RAD (rapid application development) tool. In other words, it was going to be a product presentation.

New technologies and ideas are always interesting. So I browsed Internet for some additional information about the product, and was very surprised when I found the following statement on the tool home site: ... is for developing, generating, and maintaining applications with an increase of productivity of up to 500%.

Of course, I didn't support that event...


It's a pity, that year to year IT people continue believing in some easy magic solution that will help them to upgrade their coding style, and start developing software products much faster than everyone else. Tom DeMarco and Timothy Lister wrote about the same problem in 1987... It's about 20 years ago, and nothing changed in this area.


Let's make some calculations.

Software development process consists of different activities including requirements analysis and documentation, programming, user documentation, testing, data processing, communication, management, and so on.

Industry statistics give different results, but usually programming part varies between 30 and 50 percents of total project cost.

It means that even if we automate programming process completely and it won't require any human effort at all, the project cost can not be reduced more than twice without improving other development process stages. So up to 500% productivity increase should be read as up to 42% of a project cost saving.

42% of a project cost saving? It would still be very very good, if it is possible!

A lot of developers are conservative enough, but almost each company has some enthusiasts who bring news to their teams. And if they finds something extraordinary, all team members will hear about it shortly.

So, to be 6 times (500%) away from some modern published technology, your development team has to be about 450% behind average industry programming speed. If it's the case, then it's easier to change the team than to try new technology ;-)


The following table lists some SLOC /Funtion Point values(the information is taken from QSM Function Point Programming Languages Table). A lot of languages are not being extensively developed during last years. They are quite stable and even corresponding frameworks and libraries do not grow as fast as before. At the same time, up-to-date SLOC/FP values show that these languages can compete with their more modern competitors. It's one more argument, which confirms that average software industry productivity is not increasing as fast as someone dreams.

Programming Language	SLOC / FP
Smalltalk	35
Visual Basic	50
JSP	59
C#	59
Perl	60
Java	60
C++	60
ASP	69

Myth about 80-20 rule

80-20 rule... Does it sound familiar? Oh, I'm pretty sure that all of us heard about it or even used it in business. There are a lot of incarnations:

• 20% of people owns 80% of world capital.
• 20% of your sales force produces 80% of your company revenue.
• 80% of your outcomes come from 20% of your input.
• 20% of employees makes 80% of work in a company.
• ... and 80% of employees think that they belong to those 20%.
  

and so on.

Internet is full of articles extolling this rule and its variations. I have even seen a series of books promoting a life style that is based on 80-20 principle. And it's good, until readers (and writers, I hope) remember that the figures are fake in most cases... Almost all these rules were declared without even a single statistical analysis!

Someone can say, that I'm trying to mess everything, and these rules are not about the figures, that the rules simply highlights correlation between the least part of input and the major part of output. True... but just sometimes. In other cases the results can be completely different.

Below, there are two statements that deal with the same subject as few rules listed above:

• IT people does NOT spend more than a half of their day doing nothing.
• Healthy IT company does NOT afford itself to have even 25% of useless employees. 75% would simply kill the business.

Does these statements look truthful too?

Pareto principle is great itself. Its mathematical wording is exact. But it is being misused so widely, that I would recommend to think twice before making conclusions on the base of some 80-20 rule, even if it's very popular one.

How much does an employee cost?

The case

There was an employee working for a company. He was really good in some activities, but he also got some negative feedback because of few impartial and several biased reasons. At the result, his boss decided not to raise the salary, and after few months that guy left the company.

This event created urgent demand for a new person who can take that position, and the company finally was able to find a candidate "on time":

• As always, new person required some training for that particular position;
• That new person was less qualified than a guy that had left the company, but it was the best choice in terms of cost/qualification;
  
• The company had to pay newcomer higher salary, than the previous employee would be satisfied with...
  

The question

So how much does an employee cost?


The answer

The case almost answers this question itself... Actually, it's even possible to provide exact formula (I think I can), but who really cares?..

The person who doesn't do mistakes is the one who does nothing...

One Russian adage says, that fools are being learned on their own mistakes, and smart guys on others'.

In real live, it's almost opposite. There are o lot of situations when it's easier, faster and more effective to try and check, than to spend a lot of time and effort on looking for exact solution.

Unfortunately, it's quite usual to see a person who just afraid to propose something or to ask a question, because it can be stupid. In about 60% of cases, this stupid question could help avoid some problem if it had been asked on time. The stupid question is the question that was never asked.

Another case is avoiding responsibility. You can often see people around, who was responsible for doing something, but who rejects their failure in getting results. It never helps to solve the problem or to avoid it in a future, but it always creates some confrontation with other related parties. It's so hard to work with such people in a team, isn't it? Actually, there is no need to reject or avoid mistakes. The person who doesn't do mistakes is the one who does nothing.

Most of things, I'll be describing here, came from my own experience. I learned a lot especially by taking different risks, doing and fixing my own mistakes, helping others to deal with their problems.

P.S. By the way, the epigraph (see the 1st paragraph) can also mean, that fools teach clever men, and the life is not so obvious as it seems to be... but, I still think it is.

Preface

This blog is created to collect small articles which are somehow related to software development industry. Most of these articles come from my work activities and from interaction with colleagues both inside and outside the company. Other thoughts are evoked by someone's theories or public statements.

One more source of information is professional tests and certification exams. These materials help to find gaps in personal education, to avoid reinventing the wheel and try something that everyone else knows, and... to look for more opinions.

My goal with this blog is to divide doubtful best practices, blind beliefs in standards, mythical rules formulated by an "authoritative source" from the things that really works.

Actually, I write it more for myself to have a chance reviewing these materials, thoughts, and ideas after some time... But I will be happy to receive your comments on any of this posts! That's why I added this Preface chapter. Thank you in advance!