Part 2 – Why agile, and why XP ? :
First it’s possibly best to explore why we should adopt agile (the motivation) and the component parts of the extreme methodology that I’ve chosen (personal extreme programming) and how I intend to implement those deliverables. Here is a run down of fairly obvious (or perhaps obvious points) that have lead to the development of agile methodologies :
- There are innate difficulties in developing software are human and not technical in nature. This may be through specification problems, organisational issues an external demands/threats to the survival of the project :
A founding father of the agile movement was Fred Brook. In essence what brook suggests in his article ‘no silver bullet’ is that there are two elements to all software development : accident and essence. The technological improvements over the past decades (high level languages being one of the most important) have increased the productivity of individuals to create deliverables but the fundamental human elements (essence) of software development place a fundamental constraint on achieving projects on time, on budget and to the requirements set by the project’s stakeholders.
Why agile:
Develop products with agility so that the risk of the product is shared between all the stakeholders (including the developer) equally. The delivery of the project earlier means that the project must be more flexible to embrace change.
Why the (e)xtreme approach :
This comes from a number of key principles outlined in XP :
With communication and better organization everyone in the team becomes better at what they do because everyone has a general understanding of what the needs are of the project and how they can be achieved.
Upsides/Downsides:
If you’re working in a group then having smaller specialised teams potentially avoids some of the disadvantages of scaling in larger projects (better organisation, specialisation) but also introduces the problem of co-ordinating these teams (competition and internal politics).
As an autonomous developer you do have far greater restrictions on resources and therefore ability to delegate to other members organisation of the project. The project has to be specified, designed and organised entirely on your own and this requires very good time management and planning to deliver on the project.
- Continual documentation of the project means that developers spend longer actually explaining what they did than getting the thing done in the first place.
The role of documentation is essential for development as it improves understanding in the face of increasing complexity and invisibility of the components being made (it’s sometimes hard to visualise what a class does in a real world context when data is being moved around and interchanged), and communicates exactly. Yet; a simple fact of modern software development is that programmers spend a lot of their time actually documenting what it is they’ve just written instead of actually developing the software.
The agile manifesto acknowledges this contradiction and does give some priority towards building deliverables that the customer can actually test to determine if it is as required over lengthly documentation. In this regard, PXP prioritises automated tools to save the individual developer time and energy that they often don’t have to write things like the user manual, internals documentation, or project objectives.. This may include bug tracking software such as TRAC to save in a database outstanding issues or tasks that the team must deal with and to document the project on the go with tools like oxygen .
- The complexity of modern software products/projects is increasing exponentially.
Although this somewhat relates to the next point, it’s an inevitable fact that the complexist of software projects is increasing because software. In the view of Frank Brook this is because of some of the unique properties of software, namely : the complex connection between many parts of the software; and the fact that each component is according to the conventions of OOD unique and therefore serves a singular function out of a wide range of heterogenous functions [4] . This makes maintenance more expensive (because it takes longer to figure out what’s wrong) and can often be the product of programmers producing ever more complicated structures (or castles) for which only they are the lord and master to. The answer is to spread out tasks more evenly between different members so that every member is a master of more than one, and that through a constant process of building simple code that can be thrown away and improved on in short notice.
- All projects have a birth, an existential crisis and a death.
Having a clear idea of the customers needs and designing good architecture is the only way to achieve this. The role of refactoring and simple design is what enables teams to keep code clean.
How extreme excels:
The specification of code standards, and test driven development in XP [3] gives a defined set of procedures that generate confidence in the products ability to deliver. Implementing test driven policies of writing a failed test before you write any code, and constant refactoring and integration means that the system is tested often at all levels from the single component to the overall system. The principles of simplicity mean that code can be quickly understood, and refactored to meet changing requirements. The use of version control means that if things do go wrong you can revert to a previous version, or if you can’t check in your fixes or additions for a day (or if you want to prototype a new feature with mixed confidence) you can create a new but separate version of the software that won’t affect your work thus far. It is in effect a safety net that allows you to develop code with far greater confidence, building virtual sandcastles in incremental steps instead of attempting to build them when the tide is about to come in.
Although all projects have a death date, but having clear and well defined principles means that the project won’t be at deaths door prematurely.
- Maintenance is expensive. Fix now – maintain less later!
In a typical project, Brook estimates that 1/3rd of a developers time is spend designing, 1/6th coding and 1/4th testing and system testing. Clearly, maintaining projects is a very time costly affair and additionally to this the traditional ‘water flow’ methodology means that the project can take so long to build that by the time it gets to testing the entire raison d’être for the project may not be tenable. This means that no one’s happy – the stakeholders don’t get the product they wanted and the developer gets less custom in the long run.
The agile solution is to be iterative : develop in small ‘sprints’ each with a functional and working release at the end of each cycle:
Agile cycle – source : All about agile.com
The extreme solution allows for this and more. Unlike in agile development features may me swapped in and out (with particular emphasis on swapping out an existing feature if it’s not in development to optimise the scope of the project), and prioritised according to the customers needs in cycles which typically are half the length of agile (2 weeks max) [3].
In conclusion, we can see that XP is a more defined version of the agile development methodology. When we apply this in the context of the autonomous developer in the next section we’ll look at how to implement test driven development, VCS and bug tracking as well as documentation using tools that are freely available on the web to achieve this goal.
Sources
[1] : Beck, Kent – Extreme programming Explained.[2] : Brooker -Time taken to write this : four commodores. 111
[2] : – http://www.techrepublic.com/blog/tech-decision-maker/itil-what-goes-in-a-configuration-management-plan/ – what goes into the configuration management plan.
[3] – http://www.mountaingoatsoftware.com/blog/differences-between-scrum-and-extreme-programming
[4] Brook, F. No silver bullet. http://faculty.salisbury.edu/~xswang/Research/Papers/SERelated/no-silver-bullet.pdf
// Peter Codes 