How do you like to be reviewed?
-
AlaskaDan wrote:
One of my issues is code churn. There is too much back and forth between development and QA for something the developer could have easily tested for.
Well if you are looking for shortcuts to quality I don't believe there are any. Try looking into Software Development Best Practices and Principles. You could try reading people like Kent Beck, Martin Fowler, Ward Cunningham, Alan Holub, etc. There's a quite large list of leaders in the industry these days. They don't all agree on every point but if you could implement just 10% of the 80% they do agree on you might improve your situation like 1000%. Or I have no idea what I am talking about.
led mike
I'm not looking for shortcuts to quality at all. On the contrary, I'm looking to improve quality 10 fold. Before I got promoted, you gave the developer a basic description of the feature to be developed, and sent them on their way. There was no real "end case" defined, no description of what would consider the feature complete in the eyes of the stakeholders, and certainly no definition of test cases to consider the item ready for QA. That is all changing now, but it will be an evolving process.
-
I am a former C# developer, turned CIO for a commercial software company. I say former developer because even though I open VS2005 every day with the hope of writing some code, it never seems to happen with everything else going on. I am now faced with doing performance reviews on the people who I used to code beside. The "official company document" for reviewing employees seems completely useless when it comes to developers. I have been given permission to take any approach necessary to create a more appropriate review document, so I am asking for input! What should I be reviewing the development staff on? One of my issues is code churn. There is too much back and forth between development and QA for something the developer could have easily tested for. We're going to be getting into TDD, but the review topic is still valid. How do you expect to be reviewed in a development shop where you are one of numerous developers, DBA's, architects and testers? Dan
-
I am a former C# developer, turned CIO for a commercial software company. I say former developer because even though I open VS2005 every day with the hope of writing some code, it never seems to happen with everything else going on. I am now faced with doing performance reviews on the people who I used to code beside. The "official company document" for reviewing employees seems completely useless when it comes to developers. I have been given permission to take any approach necessary to create a more appropriate review document, so I am asking for input! What should I be reviewing the development staff on? One of my issues is code churn. There is too much back and forth between development and QA for something the developer could have easily tested for. We're going to be getting into TDD, but the review topic is still valid. How do you expect to be reviewed in a development shop where you are one of numerous developers, DBA's, architects and testers? Dan
Don't review. It's as simple as that. Reviews are negative. Be supportive and helpful, and correct problems when they occur rather than waiting for some arbitrary date 6 months into the future. You do nobody any favours by letting things getting to a head.
Deja View - the feeling that you've seen this post before.