Thursday, August 05, 2010

Q&A on Refactoring and Architecture in Agile

Recently I answered a list of survey questions, on refactoring and evolving architecture in Agile project, from Lianping Chen - a doctoral researcher from Lero, University of Limerick. Here I want to share it with the community and feel free to share your comment and experiences.

1. Have you seen/experienced cases where software architecture emerges successfully from continuous small refactoring?


2. What are the main reasons that make the emerging of software architecture from continuous small refactoring success, according to your observations/experiences?

Agility in the engineering practice is definitely a must supplemented by the agility in the process as a secondary but important aspect. I also find having a light up-front design to get everybody to agree on a very high level architecture has also been very useful in guiding the refactory. Here when I talk about agility in engineering I refer to implementing the full set of agile practices: unit test, high coverage, continuous integration, refactory, and ideally also TDD and PP, since in my experience all these practice compliment each other, strengthen each other while eliminating the pitfalls that otherwise might be introduced by other practices. For example refactoring without high unit test coverage is more like hacking than engineering since you have no idea whether certain change you make will break other part of the system, and unit test without refactory will definitely introduce rigidity in architecture compounded with light up-front design could contribute to severe and rapid architectural deterioration thus compromise in quality and productivity.

3. Have you seen/experienced cases where architecture failed to emerge from continuous small refactoring?


4. What are the main reasons that cause such unsuccessful emerging of software architecture from continuous small refactoring, according to your observations/experiences?

It happens actually quite often when you have a team that only practices the process side of the agile methodology, or pick and choose some aspects of the engineering discipline for example only implement refactory but not unit test.

5. Could you please describe some cases/examples of such unsuccessful emerging of software architecture from continuous small refactoring?


If it is convenient, could you please also provide the following information?

1. How many years of experience do you have in using agile methods?

7 years

2. Which agile methods (e.g., Scrum, XP) have you used?

Both, and I prefer XP due to the fact many teams in the field that chooses to implement Scrum are the ones who choose to only implement the easy process of Agile but deliberately choose to ignore the hard engineering aspects of Agile

3. Which application domains (e.g., automobiles, telecommunications, finance, medical devices, web-based socio-technical systems, and etc.) you have been working in?

Telco, Online Gaming, and Government

4. What is your definition/understanding of software architecture? (You can refer to a definition you like or give your own understanding.)

I like Ralph Johnson's definition mentioned in XP mail listing:

In most successful software projects, the expert developers working on that project have a shared understanding of the system design. This shared understanding is called ‘architecture.’

In short architecture is a group consensus among expert developers.

One last thing I would like to mention is that initially I always believed any team can adopt Agile practice and be effective, however after almost 8 years of trying to convince and help people adopt Agile I realized that not every team or every one can adopt Agile. To successfully adopt Agile a team has to be:

  • Very experienced (PP lower the requirement of experience a bit since it helps disperse knowledge and train less experienced developer a lot more efficiently)
  • Having an open, blame-free, and trusting environment
  • Deep and thorough understanding on not just the practice of Agile but also the reason behind Agile practice among team members (An Agile coach is required if local expertise lacks in this area)
  • Having management backing and overall Agile adoption even outside of the development context

The most successful Agile adoption in my experience are the ones with all the above quality and combined with top-down support and mandate with bottom-up organic initiatives.

Hope this help a bit, and I am quite interested in your research and findings so once its published I would like to have a copy if possible.