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?

Yes

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?

Yes

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.

6 comments:

David Dossot said...

I argued to question 1 that it is impossible.

Refactoring isn't supposed to affect the behavior of a system. Hence it can't affect it's architecture, which deals with *ilities.

Nick Zhu said...

Thanks for sharing your thoughts David, however I had to disagree with that. In my opinion, refactoring is not suppose to change the behavior of the system however it can certain affect the *ilities. Imagine a online system built initially with a flat file as its data storage media, after a few rounds of refactoring without affecting its behavior the data storage media was switched to a relational database. This certainly has a significant affect on many of the *ilities, such as scalability, thoughts?

David Dossot said...

I guess it's really a matter of what is refactoring. The wikipedia definition makes me think the data store change you're referring to would not be considered as refactoring.

But the point is maybe moot because, since refactoring is about non-functional requirements, and because many consider *ilities as being non functional (to which I disagree), I reckon it's possible to consider architectural changes to be refactoring.

I still need to be convinced, though :)

Nick Zhu said...

Good point. I guess we are in fact arguing about the semantic here, since neither refactoring nor architecture is well defined in a sense. So after distilling the semantics here is the basic point I am trying convey:

The structure of a software system can be improved or built from relatively simpler form over time with small incremental changes and an iterative process, during which both unit test and continuous integration are the key enabler of such endeavor.

David Dossot said...

Agreed.

Do you think other forms of testing (I'm thinking load or performance tests) could be added to the fray. I think they provide good feedback for guiding the continuous evolution of design.

Nick Zhu said...

Agree, I think load, performance, stability and integration tests all contribute to the evolution.

In my opinion unit test and continuous integration are the necessary but usually not sufficient conditions for evolving architecture.