Month: May 2008

Mythical Great Developer

Nowadays a lot of guys are curious how to find “Great Developer” but, do not specify what do they mean by this words. How can we find something if we do not know what we are looking for? Let us at first find out is this instance exists. Probably, you are looking for a guy, who is:

  1. Knows everything on technologies she/he supposed to work with during her/his job at your company;
  2. Can create perfect easy-to-understand, scalable, maintainable architecture/code;
  3. Team player;
  4. Has nice leadership skills.

If you do, I can surely tell you that you are on the wrong way. Let me explain why.

  1. Usually, a regular human can not know every detail of every technology. Good professionals know key points and some details, not all. It means that it could make no sense to ask person for a particular details of that particular technology. Professionals usually know how to find this detail quickly, not all the details.
  2. I pointed my attention that roughly speaking all people could be divided into 3 categories:
    1. people with good memory but bad analytical skills and
    2. people who have good analytical skills and not very good memory
    3. people who have perfect analytical skills, perfect memory but do not care of your business, since whey could be perfect chess players and think about chess all the day instead of working on you
  3. On 2 I would say that usually code either easy to understand or scalable/maintainable, not both. So there are people, who writes first or second types of code.
  4. Next bad news is that usually person either hacker or team player. I knew 1 hacker on 1 project was so negative that it would be better that this guy just never participated at the project at all;
  5. And at the end leader persons are rarely good developers themselves;
  6. And now imagine of 2 hackers on the team hating each other!

We usually do not think about it when building our perfect team, yeah?

And there is even a theory called socionics that explains all types of characters and intertype relations.

Roughly speaking it tells us the next:

  • Person is either thinker of feeler, meaning either good abstract thinker or good team player;
  • Person is either sensing or intuitive type, meaning either stable worker and leader or gifted hacker, who can learn in seconds and do job better an faster than others;
  • Person either perceiving or judging meaning either strategist or tactician.

More of that, even hacker performs better if works with “bad worker” of appropriate type. And the whole team performs better if all members has non conflicting intertype relations. It is what Tom DeMarco and Timothy Lister were talking about in their peopleware than they told us about “unproductive” people on successful teams and on successful teams participating in selection of their colleagues. Does your team do it?

Even more, the Joel’s method of finding “Great Developers” on conferences could fail for Introverts, which would prefer writing code and learning new technology to participating on some conference.

But everything is not so bad. Some people advance their skills in areas they are not best in. So there is a chance you can find appropriate person or Guru. Don’t forget to ask person what area she or he is the best, what is easy and what she/he is working on.

Good luck in building your team!

Advertisement

Problems with outsourcing in software development

I actually was on the both sides. So I know how it looks like from inside and outside. I’m going to describe several problems, which you can, probably, face to, starting to work with some software development outsourcing. 1. Guys there think another way. They, probably, did not read peopleware and other books, you’ve read. They could be surprised by schedule you provide them or have in mind, but they could say nothing. Some that guys think that as they are pay hourly, it is not their problems to correct your schedule. You are lucky if have experienced team lead/PM on site to let you know about project risks. The usual rule applies: more expensive teams/companies/developers could cost you less overall. Actually the main problem here is integration. Let me tell you about 2 projects I worked for. One from outsourcing side, and another from US side. On both projects US side wrote business logic and remote team wrote UI. If you do things this way you can be already in trouble of bad integration. 2. Remote guys sleep when on site team works and vice versa. If you are lucky, you can, probably, have an hour or two of overlapping time. It means that if one of the teams have a bug it will

be fixed next day only, causing huge problems to another team. In worse case they could loose whole day. 3. If teams do not have common source repository it is another big issue. If some team do some refactoring it affects another team – other team’s code become uncompilable. Even bigger evil here is integration. On the second project I participated that way we had 2 guys on US side constantly working on integration tasks only, stating from second week of development, when we tried to integrate our code (!). On the similar project before we had only 3 guys on site doing UI, before the same task was transferred to outsourcing team. Can you imagine that? 3 guys did job here and after switching to outsourcing it were 2 guys doing integration tasks! On the first project bugs in business logic prevented UI developers from testing their code. Okay, it is not always so bad, and sure, it make sense to have outsourcing in many cases. Here is what you can do to have successful outsourcing: 1. If it is possible, let outsourcing do all parts of the job. That will save you from integration evil. Remember, that if you can’t let outsourcing do all parts of the task, integration is your biggest risk here; 2. Even if you were lucky with 1., make all your teams to write unit tests and run continuous integration everyday or even more often in all teams. It will at least help your teams to prevent most of integration issues, and help them to find their bugs earlier; 3. If it is possible, all teams should store their code in the same source control system. This will help teams to do successful refactoring, even changing other team’s code. To let it work better all teams should try to commit code before end of day, to let remote team successfully refactor. If it is not possible, new code from remote team should be committed to local repository daily; 4. Make business logic team to write all interfaces and mockups before writing actual code. The actual code could take much time, since interfaces and mockups are easy. It will also help your teams to write unit tests and to set up continuous integration tasks early. Hope it will help you to choose right way and good luck with outsourcing if you are going to use it!