AlLucky Marked 20100630

In what I'm interested today...

ASP.NET MVC / ASP.NET
Behavior Driven Development (BDD) with Cucumber and ASP.NET MVC
New Embedded Database Support with ASP.NET ([RUS] Поддержка новой встроенной базы данных в ASP.NET)

Introducing “Razor” – a new view engine for ASP.NET ([RUS ] Razor - новый движок представлений в ASP.NET)

Silverlight / WPF
Import Art from Photoshop and Make into Silverlight Controls
How'd they build that? Using Snoop and WPF Inspector to peek inside WPF Apps
Top issues for Silverlight

Management
Motivation Is In You. Find Out How to Unlock It.

Tools / Frameworks
GitHub. Introducing Organizations
[ RUS ] Обзор обфускаторов для .NET
Toad Extension for Visual Studio FREEWARE
SQL SERVER – Introduction to Best Practices Analyzer – Quick Tutorial
[ RUS ] Профилирование приложений в Visual Studio 2010

SharePoint
Developing Applications for SharePoint 2010

How to implement a task

Here is I tried to describe what I require from my subordinaries for task implementation.

During obtaining the task it's necessary to do the following:
1. Listen attentively.
2. Think
3. Write a letter in which you should indicate the following:
a) Task description
b) Splitting task to subtasks with short description of solution (if non trivial)
c) Estimation of the task with division to subtasks
4. Send e-mail and start implementation (but only after you fix remarks and bugs or write tests)
5. Approve the task (by receiving comments and approval of estimation)

Task is considered as completed if:
1. Unit tests are written
2. Task is implemented completely.
3. Whats New information file is filled
4. Files are commited to Version Control System.
5. If necessary, correspondent paragraph is added to project knowledge base.

Before starting implementation of the task (after writing task description letter to manager), following steps should be performed:
1. Fix all Critical and Major errors.
2. Fix all remarks that are not marked as POSTPONED

I hope this will help you to organize your work.

Please, advice me what could be improved here.

Thanks.

Code competition

I read "Code complete" (http://cc2e.com), 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?

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?

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.

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?

Tester-analyst

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?