Pascal Warrior's Journey

  • Subscribe to our RSS feed.
  • Twitter
  • StumbleUpon
  • Reddit
  • Facebook
  • Digg

Friday, 18 January 2013

Top Down Agile Program Development

Posted on 11:48 by Divakar Tiwari
This time I would like to post something out of coding world, but rather something about software engineering.

Traditional agile program development commonly uses bottom up approach, where one builds the lowest level functionality first then goes up further. API changes is not an uncommon things to happen during agile development, which could lead to code rewriting problems at higher level(s). For example, consider the following function:

function Init(var R: TSomeRecord): Boolean;

which somehow in the middle of development gets changed to:

procedure Init(var R: TSomeRecord);

with purpose of raising an exception instead of returning boolean value to indicate successfulness of the operation.

If this change happens in far future, then all codes using this routine must be rewritten. The problem could arise because we usually don't think how we are going to use an API, or a combination/series of them, when we design. We only think of the API as itself, standalone, away from how it will be used. Therefore, to cover the problem, we could use alternative development method, that is the top down approach.

This method requires you to build program from its highest level first (usually user interface), then goes down further. The idea of this method is largely based on test driven development, when you write test cases first prior to implementing the test unit. The difference lies in the fact that test driven development is still bottom up in the large, yet it's top down for the unit to be implemented. This method ASSUMES the lower level API already exists, regardless of its existence. So, when you code you're thinking of using the API, possibly with other API, together to do some tasks. Because of this, the changes in the future would be minimal or even none. When something goes wrong when you test, the chance is that source of error is at lower level, which means less code to change (one place instead of several).

However, this method is not magical (in fact, none is), as with other methods it has disadvantages as well. You can't see immediate result of your program until the lowest level is implemented, though you can simply put "not implemented yet" output for some functionalities. Functions with deep dependencies (e.g.: requires function X which in turn requires function Y which in turn requires function Z and so on) will be the least ones visible. This method also doesn't play well with incremental approach, which is designed to be bottom up.

Final words: Choose your weapon wisely ;)
Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest
Posted in | No comments
Newer Post Older Post Home

0 comments:

Post a Comment

Subscribe to: Post Comments (Atom)

Popular Posts

  • Encryption / Decryption and Asynchronous Socket Programming
    Back again, it's been a long time since my last post due to lack of free time and laziness :p Recently, I've got some posts in Lazar...
  • Android Programming with Lazarus through Custom Drawn Interface
    OK, so you've read that it's possible to write Android applications with Lazarus and Free Pascal. You go straight to the  wiki , fol...
  • Using Google Maps service in a Pascal based Web Application
    My final team assignment of Information Retrieval (IR) class allows us to create any kind of IR system, and we decided to create a food ingr...
  • Brook Framework, a new web application framework for Free Pascal
    Recently, a new post in Lazarus forum surprised me. Somebody, OK, Silvio, announced his new web application framework for Free Pascal with o...
  • LLVM IR Builder in Object Pascal
    I'm about to graduate from my university (January 2011 if there's no more problems), and as a final assigment (though it's optio...
  • Big mistake: wrong process model
    This is a lesson learn for application developer. Remember my last post about compiler with LLVM backend? It doesn't end happily. I didn...
  • Top Down Agile Program Development
    This time I would like to post something out of coding world, but rather something about software engineering. Traditional agile program dev...

Blog Archive

  • ▼  2013 (2)
    • ►  October (1)
    • ▼  January (1)
      • Top Down Agile Program Development
  • ►  2012 (2)
    • ►  December (1)
    • ►  June (1)
  • ►  2011 (1)
    • ►  January (1)
  • ►  2010 (2)
    • ►  December (2)
Powered by Blogger.

About Me

Divakar Tiwari
View my complete profile