Examining the Intersection of Software Architecture and Agile Philosophy
Explore the potential conflicts and synergies between software architecture and agile philosophy, addressing concerns such as the devaluation of architectural efforts, balancing development speed with technical debt, and the complementary roles of agile principles and architectural practices in promoting testability, deployability, and releaseability.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
Software Architecture Discussion David Ferry CSCI 5030 Principles of Software Development Saint Louis University St. Louis, MO 63103 1
Pro Agile Architecture Statements Big-design-up-front is at odds with the iterative agile approach that delivers value in small chunks The best teams may be self-organizing, but the best architectures require more than this There s nothing in Scrum to handle cross-team complexity Agile approach designs for testability, deployability, and releaseability Agile organisations should not create a hierarchy that places architects at the top of the tree. It is a specialism that supports and enhances development. CSCI 5030 Principles of Software Development 2
Discussion 1 Is there an inherent conflict between software architecture and agile philosophy? If there is conflict, who wins? CSCI 5030 Principles of Software Development 3
My Observations 1 The metric of working code really does devalue or discourage architectural efforts (esp. documentation) BDUF really does slow down development But, ignoring architecture concerns can build substantial technical debt e.g. Twitter case study Critical judgement call- When and how do we stop development to do architecture? How much is enough? CSCI 5030 Principles of Software Development 4
Discussion 2 If agile promotes testability, deployability, and releaseability, then what does software architecture promote? (Our case studies give some concrete answers.) CSCI 5030 Principles of Software Development 5
My Observations 2 Arch. supports testability by codifying system- internals and interactions Arch. supports deployability by isolating and component-izing software Arch. supports releasability by simplifying the scope of development work to an immediate component and its interface Developer time is a zero-sum game, like with testing, architecture work consumes time that could be spent on other productive activities. CSCI 5030 Principles of Software Development 6
Architecture Astronauts Statements Abstractions let us go up a level, but if we go up too high, we run out of oxygen Napster example: peer-to-peer is irrelevant, the fact you can listen to a song immediately is cool Using peer-to-peer everywhere is silly and over-hyped (modern comparison: blockchain) Some architectures are solving problems that are so high-level they re not real problems in practice CSCI 5030 Principles of Software Development 7
Discussion 3 Are there any times in your past where you felt that you or a project team wasted effort by focusing on software architecture? Why? (Those of you with industry experience, please share!) CSCI 5030 Principles of Software Development 8
My Observations 3 As before, allocating time is a zero-sum game. There are legitimate gripes about too abstract architectures. That said: Some technologies mentioned a lot of developers find value in : Java, XML, .NET notice he only brings up HailStorm in the follow-up piece Technologies can evolve ideas even if they re not everyday names in tech- e.g. CORBA and similar approaches defined what we now call Service Oriented Architecture (Amazon, Twitter, etc.) CSCI 5030 Principles of Software Development 9
Simple Things Statements Truly simple systems only get simpler as you dive deeply into them, some simple APIs hide terrible complexity Simplicity takes effort- Pascal s adage: I have made this longer than usual because I have not had time to make it shorter. most of the time we aren t deciding that things should be simple, which means they become complex Unit testing and TDD hint at system complexity- simple systems should be simple to test Fast iterations -> experimentation -> understanding CSCI 5030 Principles of Software Development 10
Discussion 4 Think of a software project where complexity got out of hand. What would you do differently if you had to start over from the beginning? CSCI 5030 Principles of Software Development 11
My Observations 4 A lot of concrete suggestions: TDD isn t architecture tower of functional, yet unrelated or hard to use components instead consume a system before you apply TDD Design patterns shift burden away from intuition Refactoring tools reduce friction of change Shift your reasoning to a known domain CSCI 5030 Principles of Software Development 12
Sprint 3 Retrospective Appreciation Team morale and personal relationships are especially important in small teams Relationships must be consciously fostered On a sheet of paper, write down one or two things you appreciate about each other member of your project group. (~6-8 minutes) Once everyone is done, each group member gets a moment in the spotlight as you read your appreciations aloud. CSCI 5030 Principles of Software Development 13
Sprint 3 Retrospective With time remaining, identify low-hanging fruit opportunities for your project: Consult your existing product backlog and brainstorm other features you d like to implement Rank each feature on Effort, from 1-10 Rank each feature on Reward, from 1-10 Plot each feature on a graph, where Y axis is Effort and X axis is Reward Identify groups of low- effort, high-reward features High Effort, Low Reward Effort Low Effort, High Reward Reward CSCI 5030 Principles of Software Development 14
