The Elite Team

In the early 1970s, a vice president of one of our client companies sent around a memo on the subject of travel expenses to everyone in his division. You may have received similar memos on the topic yourself, but this one was different. It said more or less this: "It
has come to my attention that some of you, when traveling on expenses, have been traveling economy class. This is not an economy-class organization. This is a first-class organization. When you fly on business from now on, you will fly first class." Of course that memo cost money. The expense was very real and the only thing you could balance against it was an enhanced sense of eliteness. At least one organization thought that was a valid tradeoff. Couldn't happen in a real-world corporation, you say? It happened at Xerox.

Peopleware: Productive Projects and Teams.
by Tom DeMarco, Timothy Lister

This is a very good sample of understanding the team spirit background. To feel and act as an elite team, its members must not just hear slogans propagandizing that they are the best. Each team member must know that they are allowed to be different, and really to be elite.

PR and hiring expectations

Today, I was told the opinion, that company public relations (PR) does not have any effect on the number of candidates "waiting in a line to be hired for the company". A background for this opinion was a statistics, that didn't reveal any hiring increase after massive PR campaigns.

This statement is probably correct... in a case when we are talking about large well-known company.

But if potential candidate never heard the company's name before, or heard the name but still has no associations with it, then chances are she/he won't pay enough attention to a vacancy. The ad can just look like a hundred other similar ads from companies, that will never give a lot of new opportunities, and that nay go out of business pretty soon.


I completely agree that PR doesn't help to hire a lot, but on the other hand its absence kills company growth.

Maintenance and Development... The difference?

"I do not want to work on a maintenance projects", - that's what can be heard from software developers and from candidates quite often. At the same time, most of them can't describe their understanding of the difference between project maintenance and project development or, in other words, the difference between the things they don't like and that they do like.


Project maintenance phase "description"

Below is the list of items that people use to describe the project maintenance phase:

1. Bug fixing
2. In few months after beginning of the project
3. When software architecture is ready
   
4. After the 1st public release
5. When you have to update other's code

So, every project, that is being developed for some time by two or more programmers and that has not failed yet, is a maintenance project, isn't it?


Why it happens

Actually, I was not satisfied with this simplified answer that every project is a maintenance stuff, so I tried to get more information about people, who insists that hates those maintenance projects. After collecting and comparing the results during a period of 4 years, I've come to the following classification:

• Husband is the developer, who works on some particular project from the very beginning, who came through a set of successful public releases, who knows about that product and its code everything. Such persons can be stuck to the project for quite long period of time and fill comfortable enough. However, one day can start "a middle age crisis". This can be a good push for "starting new life". After this point, Father hates even an idea to be involved in new long "engagement". Such crisis can be very short or long enough, but in most cases the person returns to its habits and becomes ready again for new "long relationship".
• Researcher always tries to improve something. He spends part of his work day performing planned activities, and other part looking for new information, trying different technologies. This person can be really bored by the project if it requires 100% of his time and doesn't allow experiments. A lot of people pretends to be researchers, however only very small percentage of them really are. Most projects are still OK for a researcher, because most projects are happy about introducing something that improves the result. Maintenance projects are even a land of plenty for research, because they usually do have some time for improvements. If it's not the case, then it's better to use the researcher on a different task.
• Grandma is a person who pretends to be bored spending a long period of time on similar tasks. However, such developer does nothing to change it. Such kind of a person continue using a rotary phone and hate it, but won't try a button one because "it's too complex" and she "doesn't know how".
• Pseudo-researcher is a middle between Researcher and Grandma. Such person isn't afraid of reading some new documentation, however she/he used to reject most innovations because "there is too late to integrate them into existing project". I'm sure that you heard a lot of times a phrase like: "Well, the idea/solution is really good, but it's impossible to use it on current projects because [...here some generic explanation, that fits all current company projects, goes...]. Let's utilize it for our next projects".
  
• Hack-worker is a programmer, who didn't use to do his job in workmanlike manner. Doesn't matter, if he joined the project from the beginning or when some parts had been ready. This person performs activities ignoring all circumstances, which are not directly covered by the task description. If he needs to paint a wall, he'll never be worried about keeping the floor clean. Fixing a bug, such person can create two or three new. After some period of time, when the number of project-related problems becomes quite high, hack-worker starts hating the project, and other "maintenance" projects. His favorite is to start the project and to leave it before bugs have been revealed.

What is it all about?

Good question... This analysis is one of few things that I had done before I realized how to use the results. So I was just collecting the statistics because I was interested in finding a real reason that stays behind hating "maintenance activities".

But one day, when I was involved in consulting activity related to hiring process in a company that had several software project of different kind, I returned to the same question and found out a way to use this info.

As a result, we prepared a set of questions which helped the company to classify job applicants in one of 6 ways^*, and then select appropriate project for particular candidate or do not make an offer at all.

--
^* 6 ways are 5 groups listed above + people who doesn't make too significant different between programming and "maintenance".

Formula for Success

While reading Eric Sink on the Business of Software, I've found a quote that very closely deals with one of my first posts in this blog, the one about mistakes and activities:

Would you like me to give you a formula for success? It's quite simple, really. Double your rate of failure. You are thinking of failure as the enemy of success. But it isn't as all. You can be discouraged by failure - or you can learn from it. So go ahead and make mistakes. Make all you can. Because, remember, that's where you will find success.

Thomas J. Watson, Sr., founder of IBM

If I had more time...

Sorry, this article is not intended for reading :-) It's just few notes that I want to keep for myself to return in a future (hm... am I really going to return to those topics one day?). It just like in the anecdote:

Sergeant: If your head is like a pan, and it's unable to keep anything, then get a notebook... or two as me...


So, If I had more time, I would write some interesting things about:

• Project Documentation - how to keep it actual all the time, and have people happy creating it;
• Side effect of standardization - the results of being paranoic about having everything standardized;
• Maintenance and Development. Where is the difference - by the way, where it is?
• HRs make IT salary grow in Eastern Europe (2004-2007, and may be it's still actual);
• The truth about offshore dedicated teams (companies|commands) - how these teams are being staffed, how vendors make profit, does customer have better options;

• If I had more time, I would... - how can I share time management knowledge, if I give such excuse myself? Well, I have a solution for myself, but I have some things to do that are more important for me in this short period of my life. It means, that one needs personal time management only if she/he has no enough time to complete the most important tasks.
  

Eastern Europe salaries in IT

The information below was collected from different sources in Belarus, Russia and Ukraine. However, please note that the graph below does not reflect trends for St.Petersburg and Moscow, because the statistics for those cities was significantly different in comparison with other places.




This chart can not be re-republished without written permission from Serge Stepantsov, this blog author. However, anyone can post a link to this page.

Comparison: Custom Solution vs. Standard Solution

Working on one task, I had a need to analyze the benefits of custom solution development against implementing particular standard platform.

Among other steps, I tried to do some web search to learn others' opinions, and to find out some related public materials. To my surprise, there were almost nothing published on this topic, except some marketing articles advertising their product or outsource development company. So, I've decided to publish summaries, that were collected during my analysis. Most of these materials are not related to the task I was working on and I didn't have a time to rewrite them in a better form yet (hope to do it one day), but please feel free to reuse ideas (e.g. comparison parameters) or to provide comment, which are always very welcome!

Note: in this article, Ready Solution means commercial product, not an open-source.

Attribute	Ready Solution	Custom Development
Base Product Cost		Usually, initial project investment isn’t required at all, or the amount is quite small.
Initial Customization	In most cases, ready solution requires less time to customize to a satisfactory level. However, rates for this customization are usually much higher than custom development rates.	Custom development always takes longer than implementation of existing solution. Yet, it’s still usual that Base Product Cost + Initial Customization cost for a ready solution is higher than total cost of own project.
Implementation Period	Implementation of some ready solution is always much quicker than custom development. If not, then it only means that bad product has been chosen
Licensing Fees		In a case of custom development, your usually have complete ownership over the source code, so there are no regular payments (except for some other 3rd party software, that can be required for application functionality)
Product Maintenance Cost		Custom solution is usually cheaper to maintain, because it’s possible to choose between different maintenance suppliers or even to maintain in-house. In a case of standard solution, a customer is tied to the original supplier and their exclusive rates.
Control over Product Evolution		The customer has exclusive rights to controls personal application evolution. However, if original supplier continues development of their standard product, they have a better source of information for new versions – the feedback from different users.
Product Versions	If a standard solution is being intensively developed by the supplier, it’s possible to benefit from new product versions that are being released. However, in most cases, it also means that the customer has to pay for features that they do not really need.
Knowledge Source	Usually, a standard platform already utilize some experience from the industry, so ready solution can become a good knowledge source in a product business area, if the customer has no very clear understanding for the future system.
User Training Cost		Usually, it’s easier/cheaper to train users for a custom solution, because such solutions are based on existing known company processes.
Technology Decisions		The customer has exclusive rights to select technologies that will be used for the solution. It allows to follow existing company standards (if any), or to select cheaper or better environment.
Risks	Utilizing existing solution usually has lower risk than trying to create a custom one. With a ready product it’s much more probable, the customer will receive working system on time and budget.

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.