An Introduction to Agile Methods

Via Marty Andrews, An Introduction to Agile Methods (PDF)

[Traditional methodologies] have a few things in common

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • karunnt

    About 100 years ago if you wanted to buy a car you would have to commission a person to build it for you. The bolts and nuts were non-standard.

    Then Henry Ford introduced standards and the assembly line.

    Today. How many engineers does GM empoy?

  • OfficeOfTheLaw

    I think that one should aim to develop a framework to allow for mass production, but the programmers job is still important and relevant as they can continuously work to refine the process and the code used. In short, projects should consist of custom made classes and libraries that can be tied together by someone with minimum programming knowledge, while the programmer can ensure top quality and constant refinement and evolution of those classes.

    Just a thought.

  • http://www.phppatterns.com HarryF

    It’s funny – in a way languages like Perl, Python and PHP are a step away from mass produced development.

    Think I large part of Java’s success has been the evolution of standards aimed at specifying the “nuts and bolts” and the appeal that has for project managers.

    Meanwhile an applications written in PHP usually reinvent all sorts of wheels (e.g templates) but PHP is also a big success thanks to it’s “immediacy”.

  • Amorya

    HarryF makes a good point about immediacy.

    To draw on the making cars analogy… in any craft, back when things were mostly hand made, it was easy to get started. When cars were mostly hand made, it was easy to get started learning about making them. Even when the components became mass produced but the things were still hand assembled, it was easy enough to learn about. Learning to fix the cars was also easy to start. (Of course, mastering making cars took a lot longer… but the beginning was simple).

    Now, cars are very mass-produced. To fix them, you need some kind of computer that talks to the engine and finds out what’s wrong. There’s complicated self-check systems everywhere… and under the bonnet can be mysterious in the extreme.

    The analogy is this: PHP is like how cars used to be made. Lots of people can pick up a script and hack it about a bit. Doing so might inspire them to learn more.

    Something like C++ with Microsoft Foundation Classes is like cars now. It takes a lot to get started learning what’s going on. Someone who’s mildly interested can’t really just jump in, have a play, and then get some sort of reward for their efforts. There’s so much going on that it takes a long time to learn it all.

    I think PHP should still fill the niche of the hand-assembled car. I’m learning Java now to take my software development knowledge further… but if it hadn’t been for PHP I probably would never have got started. (Memories of my aborted attempt at learning C spring to mind).

  • http://www.phppatterns.com HarryF

    To draw on the making cars analogy…

    There I have to take exception. Cars are used to frequently for analogy in software development, like every classic OO text that begins “Imagine a car…”, which for PHP developers is very confusing – when was the last time you wrote something representing a car in PHP? Using forms, for example, makes a much better point of reference for OO.

    More specifically, think using cars as a precedent for software blinds us to alot of key issues. Most importantly, as the above PDF points out very nicely, for customers the very notion of software implies infinite capacity for customization and tailoring to exact (and frequently changing) requirements.

    I have a fundamental belief (based on hunch rather than evidence) that the majority of todays software development, where there’s a one to one relationship between developer and customer, cannot be mass produced.

    Development environments that impose strict rules on the developer (e.g. everything must be an object) and frameworks that impose rigid structures will always “fail”, IMO, under a demand for truly software. By “fail” I mean significant development effort will be expended to bend the imposed rules to meet a given customers requirements.

    Where I “see the future” (if that’s possible) is with agile languages like PHP that provide the shortest path to expressing human ideas in code, rather than dealing with issues which a primarily platform / system related (e.g. memory management and by extension primitive data typing). Todays generation of agile languages could do more to make life easier but compared to, say, C it’s a vast improvement. Sadly none of the big software houses are committed to agile languages right now.

  • acpastrdarcn

    darvarouleto