I completed my PhD in software engineering at the School of Engineering and Computer Science at Victoria University of Wellington in 2014. My research investigated architecture in agile software development - investigating the problem "how much architecture?" My thesis is available for download from the university's library. ICSE, the world's number one-ranked software engineering research conference, accepted a paper based on this research for its 2015 conference. A preprint of the paper can be downloaded from the engineering school's Technical Report Series webpage.
According to the famous software engineer Grady Booch, software architecture “represents the significant design decisions that shape a system, where significant is measured by the cost of change”. Therefore, architecture design is an exercise in planning ahead – any changes made at the architectural level may require rework across the whole system. Architectural decisions include things like the technology stack, the development framework and architectural patterns. If you want to change from .NET to Java after you've started development, or change from a web-based system to a desktop app, then you basically have to throw everything away and start again.
Agile development methods are based on a development philosophy and a set of principles that allow the development team to deal with changing and unknown requirements. To accept change, agile methods discourage detailed up-front design, because requirements are not initially known and up-front design may therefore be wrong. Refactoring is used to ensure quality remains high.
Is this a paradox? How can you design an architecture while using a methodology that promotes not planning ahead? How can you use a methodology that encourages refactoring on something that can't be refactored?
This research is using the experiences of agile practitioners to explore this apparent paradox. Generally, practitioners get around the paradox by compromising -- doing "just enough up-front design". But how much is just enough up-front design? (Note: while this research is labelled "how much architecture?", it's more about up-front design and planning than specifically about architecture, if we can differentiate between them). According to a number of authors, how much? depends on context. Context include technical factors, business factors and people-factors -- the team itself and the decisions it makes.
Because of all the context factors, this research did not aim to come up with some hypothetical formula, a recipe, where you plug in a bunch of parameters (such as project size, criticality, stability etc) and come up with an answer that describes your optimal level of up-front design. Instead, this research involved talking to agile practitioners in industry to hear of their experiences and how they deal with of up-front design.
Thus the outcome of this research was an explanation, a discourse, that explained how agile development teams deal with up-front design. It is a story that teams can use to put their own situations into context, to reassure them that they are thinking about all the right things when planning -- or to give them a few ideas of things they should be thinking about.
Perhaps.
According to the famous software engineer Grady Booch, software architecture “represents the significant design decisions that shape a system, where significant is measured by the cost of change”. Therefore, architecture design is an exercise in planning ahead – any changes made at the architectural level may require rework across the whole system. Architectural decisions include things like the technology stack, the development framework and architectural patterns. If you want to change from .NET to Java after you've started development, or change from a web-based system to a desktop app, then you basically have to throw everything away and start again.
Agile development methods are based on a development philosophy and a set of principles that allow the development team to deal with changing and unknown requirements. To accept change, agile methods discourage detailed up-front design, because requirements are not initially known and up-front design may therefore be wrong. Refactoring is used to ensure quality remains high.
Is this a paradox? How can you design an architecture while using a methodology that promotes not planning ahead? How can you use a methodology that encourages refactoring on something that can't be refactored?
This research is using the experiences of agile practitioners to explore this apparent paradox. Generally, practitioners get around the paradox by compromising -- doing "just enough up-front design". But how much is just enough up-front design? (Note: while this research is labelled "how much architecture?", it's more about up-front design and planning than specifically about architecture, if we can differentiate between them). According to a number of authors, how much? depends on context. Context include technical factors, business factors and people-factors -- the team itself and the decisions it makes.
Because of all the context factors, this research did not aim to come up with some hypothetical formula, a recipe, where you plug in a bunch of parameters (such as project size, criticality, stability etc) and come up with an answer that describes your optimal level of up-front design. Instead, this research involved talking to agile practitioners in industry to hear of their experiences and how they deal with of up-front design.
Thus the outcome of this research was an explanation, a discourse, that explained how agile development teams deal with up-front design. It is a story that teams can use to put their own situations into context, to reassure them that they are thinking about all the right things when planning -- or to give them a few ideas of things they should be thinking about.
Perhaps.
