Saturday, February 28, 2009

Pairing or Pair Programming "XP Style" on a Story?

I never liked the rigid position taken by the XPers on "Pair Programming"- one programmer typing away while the other sitting next to him watching over his shoulder. People, particular PMs and clients, are weary of this practice thinking that it is a wastage of time, and hence money. I am with the PMs and clients on this. I don't like this practice because this not how we the programmers naturally work. And hence it cannot be as productive as it is claimed to be. Yes, I know there are studies throwing numbers like "15% improvement in quality while only 15% slower than two solo programmers." Why would I want to be 15% slower (hence pay 15% more) if I can maintain the same quality (difficult to prove either way though)?

I understand how this "pair programming" came about. What we the programmers naturally do is that we talk and interact with our fellow programmers sitting next to us or in front of us as we work on our codes on a daily basis. Sometimes, we look over our fellow programmer's shoulder to help or to be helped. This is natural. However, formalizing this is over the top.

What we have been doing at Code71 is what we call "Pairing on a Story." That is, at least two developers pair on a single story and take on different tasks. They coordinate to deliver the story. We usually like to pair novice-expert. This way you avail all the advantages of pair programming without the disadvantages as well as get the support from the PM or client.

Are your pairing or pair programming? Like to share your experience?

Sunday, February 1, 2009

Is Your Architecture Agile?

One of the less understood and hence less discussed topics of Agile software development is Architecture. Traditionally architecture is seen as an involved process (if done) done by some elite group of technologist called "Architect." They create these blueprints and visions that are very difficult to understand and hence probably unrealistic to implement. That is why Agile community probably carefully avoids talking about it. We cannot ignore it, yet we cannot live without it. If we do it the traditional way, we cannot be Agile. This has created a misconception among many that Agile community has discarded architecture. This cannot be further from truth.

Having practiced Agile/Scrum on small and large projects for last few years, I thought about collecting my thoughts on Agile and Architecture. So, I figured the best way to create some guideline on Agile architecture is to create a test to determine whether an architecture is Agile or not. Here is the "Agile Architecture Test,"

1. Can you describe your solution using standard well-understood solution concepts (i.e., CRM, ERP, DW, e-commerce, etc.)?

2. Can you describe your solution in terms of one or more well-known architectural patterns (i.e., MVC, Hub and Spoke, Pipe and Filter, etc.)?

3. Can you describe your solution in terms of COTS/Standard products/components (Web Server, Application Server, Integration Server, ORM tool, Database, framework etc.) using a simple block diagram?

4. Can you describe your solution in terms of a domain specific framework?

5. Do you estimate features in terms of components of the framework (domain specific) needed to be modified and/or added?

6. Do you build and run regression test as often as there are changes committed to the system?

7. Can you deploy your entire solution at the push of a button to any environment (i.e., test, integration, production, etc.)?

8. Can you determine the health of your end-to-end system at any point in time in a minute or less?

9. Does your system notify you when something is not working?

10 Can you determine cause of a problem in your system in less than 30 minutes?

9. Can you run multiple versions of the solution in the same physical environment?

10. Is your test environment an exact replica of your production environment?

11. Is your dev environment an exact replica of your test environment?

12. Can you define your production environment as a multiple of your test environment in terms of deployment footprint?

13. Can you do load testing at will?

14. Is your solution database independent?

14. Is your solution, if applicable, supports all browsers?

15. Can the deployment footprint of your solution grow and shrink with the load?

Some of the questions are more geared towards solution using cloud computing environment like Amazon Web Services. I believe cloud computing has greatly enhanced the agility of a solution architecture.

If you spend more the two weeks (sprint 0) on architecture, then you are over thinking it. Jeff Sutherland and Ken Schwaber echoed the same at the Fall Scrum Gathering in Stockholm last year. If you have an enterprise architecture guideline, that is even better. Some of the decisions have already been made for you. Architectural constraints can be liberating.

OK, I might be oversimplifying here. Sure, there are edge cases. But, the point is that most systems do not fall under the edge cases. I will be interested to know what you think of this test of agility of a solution architecture.