Friday, January 18, 2008


Formerly I thought why should we use Debug.Fail and not to use exception throwing? About a year ago I thought out the case where Debug.Fail will be better than exception throwing. But... I didn't write it down so I've forgotten it :(
But now I want to note an another case:
If we use, for example Abstract Factory of Factory Method we could use Debug.Fail.
Consider the code (it's just a sample to demonstrate one practice not all!):

public IReporter GetStrategy(Type entityType)
            if (entityType == typeof (DictionaryEntity))
                return SimpleMenuStrategy();
            else if (entityType == typeof (ProgramEntity))
                return ExtendedMenuStrategy();
                throw new ArgumentException("Unknown type of entity" + entityType, "entityType");

Than you add some others entities, quantity of them grows quickly. One day (usually it happens right before the build :) ) you add one more entity type and forget to define strategy for it. Oh, damn! Exception is generated. Not good solutions, especially if the function was missed by tester and client will see the exception message.
So, let's rewrite the code:

public IReporter GetStrategy(Type entityType)
            if (entityType == typeof (DictionaryEntity))
                return SimpleMenuStrategy();
            else if (entityType == typeof (ProgramEntity))
                return ExtendedMenuStrategy();
                Debug.Fail("Unknown type of entity" + entityType);
                return SimpleMenuStrategy();

Now we get an exception only during Debug time no runtime on the customer's side. We just return a strategy that can perform only the minimum set of functionality. May be it's even will be good enough to customer and won't turn into the fatal error that should be fixed ASAP (e.g. minimal menu will contain "Open" and "Delete" items, but won't contain "Call this person" which absence is not critical for customer for a time).

Yes, it's a fake code and a little far-fetched solution. But it works and I think works better in the second case than in first one. And general rule: call Debug.Fail where the developer's mistake that you should cover with some solution, and throw exception in other cases.

Thursday, January 17, 2008

Code competition

I read "Code complete" (, it's boring a little. But wow! One idea immediately awakes me.
Approximately a half year ago one idea appeared in my mind: code competition. But as usual I criticized it and put it to the backyards of my memory thinking I'm fool and this wouldn't help.
But now I met the same idea in that book and I decided to try it again.

So, every week developers, tester or whoever wants send me a letter with the description of the piece of work they did this week. This piece should be done in the best way and will participate in the competition. For example, developer could send the description of the module he designed, another one could send the description of the improvement she's done that greatly affects the system performance, usability or whatever else, tester could report on great job of automation library creation or full test coverage of the application etc.

Then the best one (or more) work will be chosen. The winner will be rewarded with the honor and later with the bonuses.

I think it could partially make quality better, allow to show the best approaches, code etc. But the results should be unbiassed and all the team shouldn't envy the winner in a bad way.

Could it work?

Exception rehandling

Sometimes problem of exception rehandling is occurred in the application.Consider the following situation:
  • You have a class with two methods: LoadData and GetEntity
  • You have ExceptionHandler class that handles exceptions and manages it in something way.
  • Caller classes could call both LoadData and GetEntity
  • You decided to around LoadData and GetEntity methods' bodies with try-catch and handle exceptions using ExceptionHandler.

All is ok. But imaging you call GetEntity from LoadData method and error is occurred in the GetEntity method (e.g. requested entity was deleted). Exception handler handles the exception, process it (e.g. shows message box "Object was already deleted from the storage") and .. what to do further?

  1. Return null signaling that object was not loaded.
  2. Return fake object that signaled the object was not loaded
  3. Rethrow the exception
  4. Throw another exception

Let's consider pros and contras of every approach:

Return null


  • You signal that object is not loaded, so no data will be shown;
  • Caller could check for null and make a decision of what to do;


  • Caller should always check null instead it gets NullReferenceException (the one of the worst exception I know);
  • Because null is not an often case unnecessary checks will be performed;
  • All the callers have to know about this peculiarity;
  • We should make check and make a decision again of what to do in every place we return null (in Load method and in its caller).

Return fake object

It means returning something like NullValueObject


  • NullReferenceException is avoided;
  • If null check is missing in some place we just bind an empty object;
  • Load method could not take into account return value and transmit responsibility on decision making to the caller transparently;


  • If no checks made Bind method (that binds data to the form) could bind empty object and it is good if no exception occurred;
  • We should create NullValueObject for the data for every entity. And if the quantity if entities is big and we couldn't support small count of NullValue entities support and creation of such entities could be very hard;

Rethrow the exception

I think it's a bad method at all - to rethrow an exception. E.g. if we rethrow the exception in GetEntity method, then it will be catched in LoadData method and processed in ExceptionHandler again, and there message will be shown again. I think it will confuse user (seems like, "Hey you, you can't understand it from the first time!").

Throw another exception


  • Rethrowing another exception (e.g. ExceptionHandledException) allows us to not handle in in the ExceptionHandler again but up on stack as higher as necessary;
  • It allows us not to process incorrect return values;
  • We definitely won't process empty data;
  • Load method shouldn't take care on the possible double error handling and other staff.


  • We should catch ExceptionHandledException on the highest level to not obtain UnhandledException
  • If, e.g. absence of data should be processed normally (or in another way than just catching exception) then we should try-catch all the operations that could throw the exception and process it separately in catch.
  • We should know the internals of ExceptionHandler

There are many any pros and contras in every approach. I listed only general.

So as usual, decision depends on the circumstances but the best approaches are: NullValue and ExceptionHandledException. In any case we should clearly define what is error and define the strategy on the application level.

Tuesday, January 15, 2008

Prototype it

Prototype big and/or complex methods on the natural language, write as you think, write all you think to not forget when you will start writing code. And then start coding. It helps you to avoid forgetting of something - when you started coding having clear enough plan in your mind, but something was going out of your head when you typed the code (there were so many holes, that some though in any case will slip away certainly).

I used this approach for a long time and recently found very similar one in the "Code complete". So, if earlier I thought that few people did it, now i can recommend it to use.

Monday, January 14, 2008

How to meeting

Meetings are necessary (evil). It's truth and it isn't a theme for discussions. It helps. But sometimes it can hurts the process.
One of the aspects of good meeting organization is frequency.

Every day. Actually, It wastes much time, but it doesn't give many benefits with respect to the expended time.

One time per several days (week). To organize meeting you should distract people from the working places. Because such meetings could be tightened, some people can't endure this torture and going to be bored or going away.

So how to organize the meetings? Any ideas?

Thursday, January 10, 2008

He or she?

After several remarks, united by the common theme "Why do you call tester 'she'?" (see my post I had decided to explain the reason of this.
Earlier I wrote "he/she" or "her or his" etc trying to be quite polite. But it was so ugly. So I've decided to rotate "he" and "she" in my posts. So there was "her" turn in the article about automated testers team.

Tuesday, January 8, 2008

Automate testing

If your tester have to do the same movements from day to day to check the main functionality, that is especially actual on the project release stages, than she will have not much time to test the application "intellectually". Accordingly - the quality come down. And customer's satisfaction of the project results comes down too.

I see the following outlet from this situation (this is not complete solution - but required part of problem decision process):
  1. Allocate  dedicated automation functional testing team (quite possible, it's necessary to partly put this team work cost into the project price). Why separate team? To rear an automation tester from every functional tester is expensive, long and ineffective (and sometimes is almost impossible).
  2. Tester should write a testing plan (e.g., Minimal acceptance test plan) for the automation testers.
  3. Tester should know how to execute automated tests and to analyze their results.
Thanks to this we have:
  1. Well-qualified team of automation testers, services of which could be sold and which perform automation tasks quick and with high quality.
  2. The minimal set of regressive tests, that could be run in a nightly manner, for example, for every build. It should decrease the number of overlooked errors.
  3. Increase of time, that tester spends testing the complex and/or new functionality.
  4. Quality growth
It remains just to convince boss of the truth of my words :)

Thread interruption

I think, there is a problem - thread interruption - when somebody is absorbed in his problem, and suddenly he is drawn away. May be he was diverted just for 5 minutes, but this is enough - man loses  thought and it takes much more time to collect his thoughts again, very often more than 5 minutes. He was pulled out from the thread.
If it occurs once a day, it's may be ok, but if he is important enough, it may occurs 5-10 times. Calculate the loss.

I havn't found any effective solution of this problem. But I tried several methods:

Help request via e-mail. It hadn't justify hopes. Extracts from the reports:
“Help request via e-mail, taking into account the speed of message delivery etc., was "failed", so I want to forget about it.”
“Personally, it's inconveniently for me, it's simpler when smb asks for help via Skype/ICQ with the message a-la «If you will have a minute, please, come to me" - requests of such type, properly speaking, came in the team.”

"I'm busy marks" exposure. All who is busy should exposure a special mark, for example - red serviette or something else. Was met by laugh and pessimism.

Nevertheless, all team members admitted that the problem exists, but solutions remain the old - to ICQ or Skype someone for help with the messages like "Whistle when you'll be free" or to say "Sorry, I'm busy" when somebody tries to disturb you.

Friday, January 4, 2008

Estimated development

Entrust tasks estimations  to developers, testers, technical writers and analysts.
Give them chance to estimate tasks that they will implement. Doing in such a way you will be able to plan more carefully (of course after some time during which your guys and girsl will learn to estimate correctly).
After some period of time you will see how they work - slow or fast, lazy or responsible etc. And you will be able to say - "hey, guy, you work too slow and your estimations is so-o-o big. " On the other side, you also can say - "Good job! Really good job! You grow!"

But the pitfall is in the fellows' minds. They can decide that you trust them in all and they can overestimate their work. So check the estimations, especially at first time. And if you see that somebody overestimated his/her job, stop it and talk with he/she.
And if it will continue, estimate the tasks by yourself. So you save your time and prevent dev from saying that he said that he could done the task for X days but manager said him to complete the task for Y hours.

I, for example, trust developer about 2 weeks. I think this time is not critical for most projects. The question is - should we trust from the beginning of the project, or we should set duration of the tasks and only after some time trust our devs.
The controls, of course, is necessary from the early beginning. But of what level of intention and in what form?


This idea was appeared in my head earlier but I thought that it was wrong. Many thank to Olga Gerasimenok for helping me to understand that it's not bad.

So, we propose that periodically (say - one time per 2-3 weeks) business analyst should quickly test the system and review whether the functionality is implemented correctly not from functional point of view but from "business requirements" side.

We think it's necessary because nor tester neither developers don't understand how it should be really implemented completely right. On development side only business analyst understand it right, on other side - only customer (and even not always) understand it. But rare customer will review the functionality so often and in full measure. So this duty rest on analysts' shoulders.

I've experimented with this one time. Analyst said - "it was really right solution to do this test! Good job!"

So, I think we will continue to apply this practice.

Ideas discussion

Have an idea to discuss all new approaches, methods, ideas (sorry :) ) here with the best of my colleagues to prevent from hitting bad ideas into real projects. Sometimes (I think) I produce not good ideas, even ugly ideas, but my subordinates don't tell me about this or understand the horror of idea after I announce it, and think that "It's too late to change something".
May be this blog helps us to stop bad ideas, or improve ideas before they go into production.
So the plan is:
  1. Discuss ideas  in an intimate circle.
  2. Extend the circle to all the members of the team.
  3. Publish ideas on corporate wiki.
Also I plan to write the (un)success stories about ideas implementation.
Is that right?

Brainstorm alert

Sometimes we are confronted with difficulties that can not be solved by ourselves. Especially it concerns junior developers. But their problems could be easily solved by senior developer or architect. 
But what if we struggle for a day with the problems that couldn't be solved easily even by expert. Solutions is to:
  1. Google
  2. Post a question to some forums.
  3. Brainstorming
First two points are good if the problem is common or easily describable. But what if problem is specific?
I propose to use the third solution - brainstorm alert.
Brainstorm alert is a signal to the team that some problem is occurred and it can be solved only by common efforts. This signal could be given by e-mail, IM etc. When team receive such signal they convoked and accumulate ideas may be even without immediate criticism. After the ideas will be expressed the time for criticism comes. And then the best ideas come to production.

The pros of this approach are:
  1. One head is good, more heads are better.
  2. Team feel the pulse of work and participate in complex problems resolution (I hope guys and girls will be couraged with this)
  3. Team members learn to think
  4. Young team members see how to solve complex problems and how to analyze solutions.
The contras are:
  1. Team members spend their time to solve somebody's problems
  2. Junior (and sometimes not only junior) members don't understand what is happened on such meetings.
  3. Some devs can be bored.

Other pros and contras exist, of course.  But in general, does this idea have chances to survive?