Showing posts with label q and a. Show all posts
Showing posts with label q and a. Show all posts

Tuesday, July 5, 2011

Introducing Code Reviews to Agile Practices Q&A

Question
I had someone tell me that many people in the Agile community believe that "Agile practices and peer/code review are like oil and water." I'm not sure if that's a single person's opinion or if it's a commonly held perception.  What's your view on the subject? Do you see code reviews as useful | irrelevant in Agile teams?
Answer

Statements like "Agile practices and peer/code review are like oil and water" highlight the ongoing misconception of what Agile is. Many still think that the term "Agile" equates to "No Overhead" while attributing concepts such as requirements gathering, code architecture design, QA, and code reviews as "Overhead". This is obviously a highly-flawed viewpoint.

In order to introduce and manage an effective code review process, first identify the objectives and get buy-in from the team (i.e. they need to believe in the objectives). What do we hope to accomplish with code reviews? And 'better code quality' is not an adequately defined objective -- the "SMART(ER) objectives" mnemonic can apply here.

For example, the last time my team used code reviews, we set the primary objective to significantly reduce (more than 50%) the number of staging-level bugs per iteration. The measurement was a simple bug count (admittedly crude). The time spent on code reviews was also taken into account during the estimation meetings so that our deliverables were not affected. We met the objectives of the code reviews, and continued to monitor the net value our code reviews brought to the project.

In summary, yes code reviews are absolutely part of Agile, as long as your team has clear objectives behind them that bring net positive value to the project (higher quality, more scalable / extensible code, etc). Make sure you can measure this net positive value in some way, and don't get married to the code review process itself -- be willing to change it if it's not delivering value.

Tuesday, June 28, 2011

Cloud Computing Woes Q&A

Question
For those of you who have jumped on the cloud computing train, what issues were the hardest to overcome when performing the implementation? When did you encounter troubles?
Answer

Firstly, we should keep in mind that "Cloud Computing" is simply a buzzword just like "Web 2.0", "SaaS", and even "Agile". The problem with buzzwords is that they tend to be poorly-defined; more specifically, we make up our own definition for it based on the problem we expect it to solve for us.

From my experience, I have had both the C-suite and the front-line technologists push for cloud computing. However both have had radically different motives.

On a strategy level, I think the biggest challenge is to get a clear set of expectations from those who are asking for cloud, i.e. what do you think it'll do for you / the company? Improve customer experience? If so, how? Improve productivity / reduce costs? If so, in what way? These are important questions that need to be asked before and reinforced during the implementation.

On a technical level, we used SoftLayer for our cloud computing solution and were generally disappointed with the results. I would recommend proper due diligence, and communication with the cloud hosting provider to ensure they can deliver on your expectations. Here's a useful Gartner Resource that can help in the due diligence process. If I were to recommend a cloud hosting provider, it would be either Amazon (as they are the most mature solution in the market), or Rackspace (as they have a managed cloud option).