DCSIMG

 Subscribe in a reader

February 2009 - Posts - Guy kolbis

February 2009 - Posts

I thought you might find that interesting. According to STP magazine testers choose VSTS and gave it the top spot in two categories:

  1. Dot NET Performance Testing.
  2. Integrated Test/Performance Suite.

This is cool!

One quick note is that in the Dot Net Performance Testing category, VSTS won over load runner!

More Info

Visual Studio Team Test Edition wins STP Magazine's Tester’s Choice poll …

Eyal had recently been publishing interview questions. You can read all about them here.

When I was a junior developer, I went to some interviews that asked me questions similar to Eyal's questions. In some cases I knew the answer, in other cases I knew part of the answer and sometimes I did not know the answer at all.

Does it mean I am not a good developer?

Does it say something about me?

Am I not good enough?

At the time, it made me question my capabilities. After bad interview I did not have much confident at myself. Since those times I have grew and learned. I had evolved as a Developer, Architect,  Project Manager, CTO, Consultant and etc.

Speaking for experience, I must say that those interview questions really guaranty nothing. When I interview someone, I usually use a more common scenario and questions that are relevant to the current project we are working on. For instance, if we are developing a web application, I would ask for a simple web application that is connected to the database and displays something.

Having said that, in some cases those tricky questions will be valid but most of the time I prefer not using them. Instead, talk to the candidate, hear what he has to say and just "flow" with his knowledge and capabilities.

In my opinion, each candidate has different potential. You should not always use the same "template" and questions for each candidate.

What do you think?

Agile adoptions can go wrong in many ways. It can be lack of commitment, lack of support from the management, lack of knowledge and experience and many other reasons.

It may surprise you, but lots of companies that practice Agile development fail or challenge. In my opinion the number one cause for this failure is "Gradual Change".

What is a Gradual Change?

Usually when a company decides to be "Agile" they will make some efforts to change their their work habits and development process. They'll try, and they'll make changes... But the changes will be "gradual" and not "transformative". You see, Agile has some "transformative" practices such as TDD (Test Driven Development), Collective Code Ownership, Pair Programming, On-Site Customers, Not Bugs and many others. These practices are also the most challenging and hard practices.

Most teams will try to "gradually" change into practicing Agile. In practice what will happen is that most of them will select what they will actually practice. Most putatively Agile teams  will not do most of the above examples and only few will do some all of them.

Waterfall teams will make smaller waterfalls.

CMMI teams will have smaller phases.

Document-centric teams will streamline their documents.

When you gradually change, you select a practice and implement it, for instance, you can introduce iterations, and then TDD and so on and so forth...

Will that work? It might and yet again is mostly won't.  

According to James Shore:

"...Teams take years to get through this list, and it's exhausting. I don't know any that have made it. Really! None.

..If you adopt [Agile] incrementally, every new practice will disrupt the equilibrium you'll be fighting to achieve. You'll actually extend the period of chaos and uncertainty, making the transition all the more difficult."

Absolutely right!

Summary

In my opinion, some things can't be reached with gradual change. If you decide to go with Agile, you need commitment, understanding and knowledge.

As Tobias Mayer said:

"...[Agile] does not actually DO anything. People do things...if taught effectively gives people the opportunity to wake up to themselves. If they don't they'll go out of business... Apart from a manifesto, Agile isn't actually anything.".

Remember that Agile is just a trendy word.

kick it on DotNetKicks.com

A new release for jQuery 1.3 is out.

image

Read more about it here.

Downloading

kick it on DotNetKicks.com

I am currently visiting a customer in England, where I am helping this customer to define the process that will be used for all future projects.

We have talked about Agile, CMMI, XP, SCRUM, Waterfall...

We have talked about Team System as a tool to help them manage that process.

We have talked about...lots of things...

So would you like to get a snick pick to some of the things we have talked about?

Here are some pictures from our white board that demonstrate that:

תמונה000

תמונה017

תמונה016

You see, Team System is a tool and software development is an Art (and a well defined process). As I like to say (Steve, this one is for you...):

"A fool with a tool is still a fool"

Cheers.

I am sorry that lately I did not blog. It is crazy for me right now... Lots of work and not enough time... Do you know the feeling that you wish there were 30 hours a day rather than 24 hours?

Anyway, I am on my way to England and I hope that I will have the time while I am there to share some of my experiences and wisdom ;-)

kolbis כתב בתאריך Sunday, February 15, 2009 4:24 AM
תגים:

PAG_Logo_NoText

Grigori Melnik, who is the PM for EntLib over in Patterns & Practices, posted about planning version 5.0 features.

According to Grigori and I quote:

"We’ve started our planning of the Enterprise Library 5. This is your chance to send us suggestions, comments, screams... These may include ideas for new blocks, new providers for existing blocks, integration with new .NET Framework 4.0 features, improvements to the design-time experience, performance improvements, support of specific deployment/operations scenarios, documentation/training support etc."

This is your chance to help steer the product.

Read more about it here.

kick it on DotNetKicks.com

How would you describe the way that decisions are being made in your software development cycle or in your company?

Is it Democracy?

Is it Dictation?

Is it Anarchy?

Here is a sentence I heard from one of my customers:

"This is not democracy, I am the manager, I decide what to do"

I believe that software decisions should be reached only if excepted and agreed by the team. Any input can be helpful and should be considered. Team member may have an opinion that can lead to a better solution.

Having said that, there is a possibility that the team will not agree on something. What then? I think that a good team can reach an agreement. In order to reach one, the team or one of the team members should sometime "climb down from the tree" or make compromises. It does not matter what your title is, whether you are the manager or a developer, use other team members to help to reach the best solution. Sometimes, it is not simple nor easy to give up your ego. If still the team cannot reach an agreement, someone should help the team reach one.

It is very easy to manage the team by authority and say something like "I am the manager...". I think that a true manager or a leader is one that manage the team without having to use authority.

What do you think?

kick it on DotNetKicks.com