ATSC Podcasts: Evolutionary Design
Full podcast transcript enclosed below:
Slide 1 – Evolutionary Design
Welcome to this podcast on Evolutionary Design my name is Ali Ali. I am a principal consultant with Technology Services at ATS Corporation. I’ve been with ATS Corporation for a couple of years. I came to them through the acquisition of Number Six Software, before that I was with IBM Rational for 12 years.
Most of what I do is work with clients to help them improve their architectures and their processes to achieve significant improvements in software development.
Slide 2 - Agenda
What were are going to cover today is to talk about what Evolutionary Design is and how it actually evolves through the approach to agile development. What happens after when you start agile development using users stories and how does design emerge and evolve after that and then we want to emphasize that just because we are following an agile approach and letting design as evolve as such that doesn’t mean we are ignoring architecture and finally we will cover quickly what ATSC can do for you in this regard.
Slide 3 - What is Evolutionary Design?
So Evolutionary Design is an agile approach to designing software where the design can emerge from code as it gets written and re-factored trough test driven development. In my experience I found that the best way to learn new concepts such agile development and evolutionary design is to compare it to concepts with which you are already familiar. So this approach to Evolutionary Design contrasts significantly with the older iterative approaches as well as the Waterfall approach where you do requirements in its entirety and then freeze it or whether you do the overall Waterfall or a mini Waterfall in the traditional iterative approach and then you do design and then you do implementation and testing. So these you do in a more or less in a sequential way in an iteration or the entire project where as in the Evolutionary Design you are following a much more agile approach.
Slide 4 - So how does this “Evolution” progress?
In that agile approach to begin with instead of the detailed textual requirements that we do in the more traditional approaches and the detailed description of UI documents. What you do in an agile approach is you probably would start with a user story or set of user stories. A user story is essentially a title with two or three sentences. It is very similar to what we have for brief descriptions of use cases. To detail the requirements any further you would have in an agile approach you would have to engage the customer throughout the development to obtain the details of those requirements incrementally subsequently through the agile approach.
Slide 5 - What happens after user stories?
So developers after they start with user stories what they do is then they write unit tests to test the functionality represented by user story and those tests are going to be written before writing the code that the tests are written to examine or test. The test won’t pass at first because you haven’t even written the code yet to implement the functionality. So what you do is after you write unit tests you ahead and implement the functionality in a minimal way just to make the test pass. Now this test driven approach doesn’t only ensure that code maintains high quality, but also serves as documentation of the public interfaces of your code. In other words it serves to document how you want the functionality to be used. This is often known as programming by intention.
Slide 6 - Ok, so how does the design emerge and evolve?
After you right the minimal functionality necessary to make the test pass either the developer will then incrementally flesh out the functionality by adding one little increment at a time and after each increment the developer would then run the test again, fix any detected bugs and re-runs the test until the test method produces no errors. Through that cycle of writing code and testing it the developer periodically re-factors the code to eliminate duplication, remove any ambiguity, and make the code adhere more faithfully to design standards etc. In other words eliminate what is sometimes as known as technical debt in your code. So continual input is then sought from customer as to the expectations of the functionality that jives with what mention earlier with seeking the details of the requirements for the functionality from the customer. The above cycle of testing, coding and refactoring grows the code incrementally and gradually formulates design patterns for all of your functionality throughout the software system.
Slide 7 - Are we ignoring architecture and modeling tools here?
So, just because we are growing design in such an agile approach does not mean that we are advocating against using the architecture discipline or using modeling tools. So for example to accommodate scalability, early agile iterations that is to say sometimes those agile iterations are called sprints, those early sprints can implement functionality that verifies the architecture is scalable that we can focus on fortifying the architecture and stabilizing the architecture and then proceeding with the normal agile approach.
Slide 8 - What can ATSC do for you?
The agile approach is not always better than other approaches regardless of the development needs and the nuances of your organization. What our cumulative experiences has shown is that each organization needs to determine, with the help of experienced resources such as ATSC consultants, the optimal approach for its own needs based on factors such as geographic distribution and culture. Experienced resources from ATS Corporation can help a client organization customize a suitable approach, which is likely to be a hybrid between the traditional and the agile approaches.
Slide 9 - Contact ATSC
You are more than welcome to contact ATSC using the contact information on this slide. We thank you very much for listening to this podcast.