Skip to Content
Agile methodologies views software development in a different perspective. It does not compromise on quality but at the same time makes it interesting for developers and architects.(This I personally feel the waterfall model fails to do.)

I would breifly describe the striking concepts of Agile and then give the links to better and exhaustive documents for you to explore. I strongly feel that this way of software development should be interesting and also is worth experimenting on.

Test Driven Development

  • Write the test cases first and then start developing. Tools like JUNIT are used here.
  • Iterative Software Development

  • Software is developed in cycles.
  • Every cycle produces a production quality, running, integrated software although with a limited functionality.
  • Typical iteration cycle even for large-scale projects ranges from 2 to 3 weeks.
  • Upfront Design

  • Customer is a part of the development team.
  • No Elaborate design.
  • Design for a small functionality is discussed and the development is started right away.
  • The design actually happens while coding and integrating.
  • Lot of code gets eliminated in this process but the final product is of good quality. (OS’ like Unix and Linux was designed this way!)
  • Design patterns are used extensively during implementation.
  • What about quality?

  • There is a quality team involved in every iteration.
  • They check the code, how it integrates and also the test cases.
  • No Elaborate Documentation.

  • Documentation is done but it is done to the minimum.
  • UML is used.
  • The code is written in such a way that the variable names,method names etc are self-explanatory.
  • There is more to Agile than what is described above. Please visit the following sites to know more.
    Extreme Programming

    So shall we get Agile….

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Former Member
    I agree whole-heartedly with such approaches, serious developers know they are just plain common sense.

    Unfortunately the chances of seeing such practices in the consulting workplace is next to none.  They are at total odds to the long drawn out approach adopted by system integrators / larger consulting firms.  These organisations love to have big milestones (and contractually get paid accordingly) with reams of useless documentation as deliverables.  Unfortunately many customers see this as “value” but in reality it is unnecessary cost.

    Perhaps I am too cynical…


    1. Former Member
      Maybe just a little cynical.  I like this approach but I can see for sure that this could be seen as a bad method for customers, ever evolving design and functionality every 2-3 months is not something you want to put your users through.  Or maybe I am misunderstanding something.  I like the documentation part as well. 
      1. Former Member
        These short-cycle approaches do not necessarily need to mean deployment as well, rather just cutting a big effort into smaller efforts.

        Also we should be mindful that such development methodologies are more aligned to the development of software products, rather than the customisation and implementation of large suites such as SAP.


      2. Former Member Post author
        Yes, Ever evolving design is a part of the complete development of the product. Once the product is completely developed and delivered nothing more needs to be done.

        Here I believe we are too much limiting our discussion to documentation. Documentation in this methodology does is not zero but it is just what is needed. The design is documented, the code is commented to the minimum and the code is highly modular and clear.

        It is not like having a function module for 1000 lines out of which 200 lines are commented with variables and name like l_ab and m_ac which doesn’t make any sense.

        Its like having small function modules of 200 lines with 10 lines of appropriate comments and names like table_business_systems, var_account_number. Now doesn’t this sound simpler.

        Moreover the other development processes like upfront design (as against prparing 10 different sets of class and sequence diagrams and getting confused about what to do) and test first approach are really good enough to experiment on.

    2. Pankaj Kumar
      Developers and IT people who are going to manage the solutions when you are gone are two different breeds. Typically consultants are paid big bucks(I am reminded of that every day, is that right guys 😀 ) as they are supposed to have this vast knowledge they would have acquired from implementing same product in different environments. While guys managing the solution would be limited to the local environment. This is the reason IT managers typically like to capture all the information they can while product is being implemented. And what is the best way of capturing Documentation 😀


      1. Former Member
        All for documentation – but it has to be meaningful documentation.  In my opinion what makes documentation is:

        1) Clear explanation of the requirement leading to the development.

        2) Plain language explanation of the intended solution and if relevant reasoning for rejecting other solutions.

        3) High-level explanation of the components representing the solution and in particular how the relate to one another.

        When I write documentation, I always write it with support personnel in mind.  These people (having been there) are not concerned with low level details that can all too quickly become obsolete.

        I always leave lower level documentation to the commenting in the code (and in many cases it is extensive).  The reasoning for this is:

        1) It quickly becomes obsolete.

        2) This level is too low for a design document as so often the approach taken at a low level will be different to that envisaged, even though the higher level approach remains the same.

        3) When supporting, the first place I have known people to refer is the development itself.

        The common approach that I find costly and of low-quality is where a company requires a detailed low-level specification to be written by one person before doing the development work.  Even worse when the subsequent development work is done by someone else.  I see this all the time.


    3. Just a second comment, while I’m at it: I don’t agree with the opinion that we won’t see this methodology at work anytime soon. I already made my comparison with the dinosaurs, and this is exactly what will happen. The world is moving slowly from dedicated monstrous systems to reusability, modularity, web services, open source… which is exactly the environment in which techniques like XP will thrive.

      Although it might take some time before the “big” consultancies switch their focus or even dare thinking about forsaking their favourite methodologies, smaller companies will eagerly start applying these techniques and gain market shares as a consequence. They will eventually gain the upper hand, and their larger counterparts will necessarily have to follow, much like SAP when it “discovered” and embraced Java, open source, xml, Eclipse, web services…

      I sincerely hope this means a paradigm shift in the world of systems development. I personally resist the idea of wasting even a single neuron’s worth of brain activity on anything that doesn’t add direct sustained & proven value to anything I do, and I’ve choked on methodologies for close to twenty years now… one way or another, they always bring associations to Scott Adams … 🙂

      I think we all clearly see the benefits of these new ideas, if put to use in a structured and pragmatical way. We probably also know a lot about projects that were crushed under the sheer weight of their own piles of documents…


  2. Former Member Post author
    I am not able to understand why did customers emphasise on whole lot of peripheral deliverables like design documents and documentation for each line of the code.

    I feel that this was because earlier, customers were unaware of the coding part of the software and so they wanted something understandable written about the product.
    But at present I beleive the customers understand the code really well and now we can definitely switch to these kind of approaches where a highly modular, self explanatory and high performance software is preferred to non-modular, normal performance and highly documented code.

    And please note that the customer here forms an integral part of the development team and the approach is iterative as against water tight phases.

  3. …this is the way I’ve always worked…

    Seriously; it’s great to see a breakaway from the tedious mammoth methodologies from the 80’s and 90’s. Like the death of the dinosaurs. 🙂


Leave a Reply