CODE AND FIX
One of the original concepts for software development was the Code and Fix or Big Bang. In this style of development a person or team would write some code then fix what was wrong. This is perhaps the way many people start coding as it is simple is nature and lacks real thought or study to accomplish. Code and Fix’s biggest advantage over its peers is that you begin to develop right away. Much in the way a beginning CS major will face their homework. Although, this “advantage” is also one of the biggest disadvantages of using Code and Fix. Software for the real world is complex. A designer has to worry about security, multiple platforms, and making sure their actual software runs! Code and Fix is in no way a logical method to develop anything besides “Hello World”, and that maybe pushing it depending on the complexity required.
Following Code and Fix, Waterfall was the next major software development style to be used. Often called the classic development cycle, Waterfall cleaned up the design process. In waterfall six major steps are rigidly followed. First are the requirements of the software. This would entail the purpose of the software and its platform needs. Second is the design of the architecture of the program and its UI. Third is the actual coding of the program. Fourth is the integration of the software into its environment so that it may be tested which is number 5 on the list. Six which is the last step is deployment. Deployment comes after the software is found perfect enough for the end user. The software will not be completely finished but that’s what updates are for right? The biggest hurdle teams run into when developing using the Waterfall method is that it is extremely difficult to go back a step. Each step is thoroughly documented and trying to back would require a lot of re writing and editing that on a large scale is not realistic. Leffingwell writes”… but in any case it’s clear that misunderstood and changing requirements had a huge impact on project success…” (Leffingwell). This lack of agility to fix something in a previous step leads us to our last development mythology.
Agile is so named because it is nimble in the development of software. Although Agile has a set of steps that need to be followed for a successful product it does not punish a team if they need to change an idea or design. In Agile a team is able to nail down exactly what they want in their software in what is called User Stories and backlogs. The team goes through a series of Sprints to complete their backlog. At the end of a Sprint a Sprint Reflection is performed so that the team can discuss things they liked and didn’t like during the Sprint. All the while this is happening the team meets each morning for a Scrum, so that they can discuss what is happening and to make sure that everyone knows their rolls and how to accomplish their tasks. In Agile the developers use quite a ingenious way to come up with ideas for their product. They create User Stories which are told in the perspective of the user. A sample User Story would be “As a user of X program, I would want to know how many hours I spend doing Y”. The Team then uses this to create a Backlog for them to work on. Scrums, Product Backlog, and Sprint Reflections may sound foreign now but throughout these blogs I’ll be delving more in depth into each topic.
A visual interpretation of Agile vs. Waterfall
Images courtesy of: http://sqtc.wordpress.com/2012/01/04/software-development-life-cycle/
Ambler, S., & Holitza, M. (2012). Agile For Dummies®, IBM Limited Edition. Hoboken, NJ 07030-5774: John Wiley & Sons.
Leffingwell, D. (2010). Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley Professional.