none
Planning development process RRS feed

  • Question

  • Hi All!

     

    Programs I wrote were usually small programs and I don't have experience in development medium and huge programs. I'd like to know what you, experienced developers, usually plan your developement process?

     

    1. I tried to start from database design and I have already one, but incomplete. I cannot design the whole database in advance. It's getting grown as needed. Is it ok or I'm doing it wrong?

    2. When database is ready somehow I start coding of course by defining objects

     

    Maybe there's some resource I can read in the web?

    I would appreciate your help!

    Thank you!

     

    Thursday, October 16, 2008 10:49 AM

Answers

  • It depends on the project and client but I prefer to use Extreme programming, Agile & Scrum methods. 

     

    I find these to lead to successful developments because it puts the focus on the client and providing the most benefit to them through your developments.

     

    In my developments this leads to prioritising development by function (user story) rather than technology.

     

    When developing a database application this may mean developing the user interface for a particular requirement, then the parts of the database that are required for these screens, followed by the business rules and data access for that part of the application.

     

    see the below links;

    http://en.wikipedia.org/wiki/Agile_software_development

     

    http://en.wikipedia.org/wiki/SCRUM

     

    http://www.amazon.co.uk/Extreme-Programming-Explained-Embrace-Change/dp/0321278658/ref=sr_1_1?ie=UTF8&s=books&qid=1224157401&sr=8-1

     

    http://www.amazon.co.uk/Agile-Software-Development-SCRUM/dp/0130676349/ref=sr_1_10?ie=UTF8&s=books&qid=1224157425&sr=1-10

     

    hope this helps

    Thursday, October 16, 2008 11:50 AM
  • I've found that the most unpredictable piece of medium to large scale development is the data layer, no matter how good our business and technical designs are, the database will stay in a constant state of flux through that 'bell curve' part of any development process. 

    To account for this, and changing/evolving requirements, we start a project by doing a large scale technical and database design up front, break the features into pieces that can be reliably detailed designed and coded / documented and tested in ~3 week periods.  That will give us our initial high level time estimate.   During those 2-4 week periods the database/business layers and even customer requirements evolve, in the middle of the project at a very high rate. 

    The articles that I suggested have to do with generating the data access and generic business objects on the fly as the database and requirements evolve.  This allows the developers to create/modify datastructures quickly without the 'that will take days/weeks'... an additional field should take minutes to add to a table including all supporting code and scripts.  (I am being generous)

    So to answer your question and tie this together, our process is agile or scrum based as
    Gmoore pointed you to, the implementation or technical foundation of the process is the generated code as well as automated builds and automated unit tests...  The project I am currently on has about 11 developers and has been in development for a bit over a year and uses this high level overview / drill down in 2-4 week cycles with code generation and automated builds (even database is rebuilt and data migration scripts are automatically run each night).  It seems to work well for us.

    Does that help?
    Friday, October 17, 2008 1:44 PM

All replies

  • It depends on the project and client but I prefer to use Extreme programming, Agile & Scrum methods. 

     

    I find these to lead to successful developments because it puts the focus on the client and providing the most benefit to them through your developments.

     

    In my developments this leads to prioritising development by function (user story) rather than technology.

     

    When developing a database application this may mean developing the user interface for a particular requirement, then the parts of the database that are required for these screens, followed by the business rules and data access for that part of the application.

     

    see the below links;

    http://en.wikipedia.org/wiki/Agile_software_development

     

    http://en.wikipedia.org/wiki/SCRUM

     

    http://www.amazon.co.uk/Extreme-Programming-Explained-Embrace-Change/dp/0321278658/ref=sr_1_1?ie=UTF8&s=books&qid=1224157401&sr=8-1

     

    http://www.amazon.co.uk/Agile-Software-Development-SCRUM/dp/0130676349/ref=sr_1_10?ie=UTF8&s=books&qid=1224157425&sr=1-10

     

    hope this helps

    Thursday, October 16, 2008 11:50 AM
  • Sounds good. Thanks a lot. I must read this.

     

    Thursday, October 16, 2008 12:13 PM
  • I would suggest investigating object relational mapping and possibly get a code generation tool that can generate your data access code in a manner you decide.  Either through scripts you write and enhance yourself or use templates that the community has built.  NHibernate and Mygeneration are two good free popular tools for .Net

    See this for further info:

    Steve
    Thursday, October 16, 2008 5:16 PM
  • Steve, maybe I misunderstood, but this article has to do with the design of data access layer. I'm interested more in development process, planning development process. I already have my own preferred data access layer. Gmoore's article suits me well, because in my case the needs will change during development. How do you usually plan you process? is it 'on fly' or whole process is planned in advance?
    Friday, October 17, 2008 4:51 AM
  • I've found that the most unpredictable piece of medium to large scale development is the data layer, no matter how good our business and technical designs are, the database will stay in a constant state of flux through that 'bell curve' part of any development process. 

    To account for this, and changing/evolving requirements, we start a project by doing a large scale technical and database design up front, break the features into pieces that can be reliably detailed designed and coded / documented and tested in ~3 week periods.  That will give us our initial high level time estimate.   During those 2-4 week periods the database/business layers and even customer requirements evolve, in the middle of the project at a very high rate. 

    The articles that I suggested have to do with generating the data access and generic business objects on the fly as the database and requirements evolve.  This allows the developers to create/modify datastructures quickly without the 'that will take days/weeks'... an additional field should take minutes to add to a table including all supporting code and scripts.  (I am being generous)

    So to answer your question and tie this together, our process is agile or scrum based as
    Gmoore pointed you to, the implementation or technical foundation of the process is the generated code as well as automated builds and automated unit tests...  The project I am currently on has about 11 developers and has been in development for a bit over a year and uses this high level overview / drill down in 2-4 week cycles with code generation and automated builds (even database is rebuilt and data migration scripts are automatically run each night).  It seems to work well for us.

    Does that help?
    Friday, October 17, 2008 1:44 PM
  • I also find project retrospectives useful.  In this you and your team consider what you did well, what part of the process or development you would keep and how you could improve.  This is documented in reference architecture documents and is shared across our development teams.

     

    In the past I have created reference architecure documents that describe the good parts of our design and the problem it addressed.  These can then be reused in the next similiar project (with necessary changes to fit in with anything unique of course).

     

    I have reference documents that describe, among other things, the data access strategy for the different types of project I have worked on.  In these documents I also include documentation tools, collaboration tools, design patterns, source control tools, IDE's, SDK's, frameworks, software development methods, processes etc.

     

    I think these retrospectives help improve our development methods and processes as well as how well we utilise the available technology (I think this is what psteve was trying to describe to you).

     

    The below book is the next on my reading list

    http://www.amazon.com/Agile-Retrospectives-Making-Teams-Great/dp/0977616649/ref=sr_1_1?ie=UTF8&s=books&qid=1224252132&sr=8-1

     

    Friday, October 17, 2008 2:06 PM
  • GMoore, Steve, thanks a lot for help!

     

    Monday, October 20, 2008 5:32 AM