Coffeehouse Thread

17 posts

Build the database first, or the application first?

Back to Forum: Coffeehouse
  • User profile image
    ktegels

    My co-worker Larry asked that question, and then offered the following...

    Continued here.

  • User profile image
    miies

    I second all of the four arguments that you state on the webpage. Frankly, I can't imagine ever building an app first. If one of our customers (to be) wants to 'see something', we just create some drawings/sketches.

    Edit: non-argument removed.

  • User profile image
    Lwatson

    I agree with most of your observations in basis. I do however think that your term of design the database might be a little to literal. For example...

    Sometimes the requirements for an application or process are already set up. The case of something that needs to create a certain set of output in a certain format for example I will use a report that needs to be sent to a governing body on some periodic basis. In this case there are already a well defined collection of items that are necessary to fulfill this requirement. If you are developing a single application to fulfill this requirement then your 'DATABASE' is for the most part already defined. Data storage specifics like what kind of normalizations and what not need to be ironed out, but in these case ( and they happen quite frequently ) It might be possible and even prudent to conduct a limited batch of human interface building before you actually get into the nitty gritty of the database design. You already have what you need to gather or have the user(s) interacted with. Some level of ui development might show how far you should take your normalization efforts.

  • User profile image
    Manip

    In my opinion it should not matter if you've doing your job correctly. If you have designed the project fully
    whichever one you build first should correctly link to the other. This question is an issue because your designing and building your project at the same time, maybe you should have it set out on paper; it would stop you have building one and then going back and altering that because something unexpected turned up in the other.

     

     

  • User profile image
    Jeremy W

    In my opinion (very humble one) it's semantics. You should be following a process whereby the application is very clearly defined, analyzed and spec'd out before you get anywhere near code (beyond proofs of concept) or the database.

    A detailed spec should be enough to give to users, give to application developers and UI guys as well as to database guys (again, in my opinion).

    I prefer to work with all the key groups (both customer groups and internal) to the point where everyone knows where the project is going (at least to some degree, it's the PM's job to know more obviously).

    By the time a developer really gets his hands on it, the "chicken or egg" should really be semantics. I mean you'll have already spec'd everything out, gotten sign off on business requirements, done demos, flowcharted everything... By the time the real milestone one development starts the difference between which goes 'first' should be incredibly small.

    That said, I've seen huge succesful apps built both ways. It's really a Project Management issue to ensure that the teams remain engaged and efficient.

    ... All of that said, I prefer to see the Database first as, between that and flowcharts, it gives me a real feel for the application's direction.

    I guess I'm unique in that I started out doing UI design, then moved to programming and then moved to Project Management.

  • User profile image
    ktegels

    Manip wrote:

    In my opinion it should not matter if you've doing your job correctly. If you have designed the project fully
    whichever one you build first should correctly link to the other. This question is an issue because your designing and building your project at the same time, maybe you should have it set out on paper; it would stop you have building one and then going back and altering that because something unexpected turned up in the other.



    Ha! For once we agree on something Manip!

    Still, no matter how well and how exhustively we design something, we still find unexpected things turn up. Its the nature of our organization.

  • User profile image
    Jeremy W

    For sure, nothing's ever perfect. But we have to at least try and have perfect processes (or processes that work) and best practices to try and avoid common mistakes...

    Or at least have the appearance of it so that when people ask why there are swear words in your code you have something to fall back on Wink

  • User profile image
    Manip

    Due to the nature of business application programming most projects turn out roughly the same. You can use this to your advantage, first design a project.. do it really well almost perfect, design it with no cut corners. Then next time a project comes around that is similar you can just copy and paste, do some editing and you have a new design and already have 90% of the code done. It is dangerous because you could forget to change the design but the benefits outweigh the risks.

  • User profile image
    teknologikl

    ktegels wrote:
    Build the database first, or the application first?


    I choose C) None of the above. It's obviously a trick question; we all know the correct answer is "object model first."

  • User profile image
    Sabot

    Guys, guys, guys! Hang your heads in shame! Have you never read a UML book? Jackson? Yourdon?

    The way to design a system is

    1) Establish the basic data items BEFORE you 'mock up'!

    2) Building prototypes (@cough@ we call them 'mock-ups' these days Sabby) to shake the detail out of the users. This also manages the users expectation of what they are going to get delivered.

    Mind-you there are so many techniques to get the detail out, from spotting nouns from a definition of the business process written by a Business Analyst to 'role play'. There are hundreds of them, read afew books and try things out ... but ... and here comes the BIG warning !!!

    "When listening to a users requirement, DO NOT START CODING THE PROJECT ALREADY IN YOUR HEAD"

    Get the requirement down in black and white agreed ... and sign off, before ... 1 ... line of code !

    Leave that to the Software Architects ... opps can't call yourself an 'Architect' in the UK, unless you have a licence to design buildings, the rational being that only qualified people can design buildings, so therefore they are the only people that can legally hold the title 'Architect' ... can you draw a three-bed semi??? No! Change that job title now!

  • User profile image
    Jeremy W

    I can actually do a 3-bed semi (took 4 years of architecture before getting into programming), but that's besides the point. Besides, I refuse to hang my head in shame (read my post) Wink

    There are, actually, a lot of really good programming and development methodologies out there. I'm fairly sure the Microsoft PM's have some decent ones too... If they feel like commenting Smiley

    How was Channel9 built guys?

  • User profile image
    JParrish

    For business applications, particularly if it is for a client that does not have much experience working with software developers, it is best to start in neither the application or the database. Instead I prefer something like object role modeling to help get a solid conceptual model in place. This model is in part based on examples of data that the client can provide, and mostly on questioning of the client as to what their current workflow is like. You translate the customers comments into elementary facts, set the constraints, and populate it with the data the client provided. In the case of ORM, a well defined conceptual model will do several things:

    1. Provide a verbalization of the universe of discourse for easy validation by the client
    2. Provide a firm foundation for the formulation of an SRS
    3. Create a fifth normal form ERD for you and generate the database on your specified target


    To me: conceptual model, then data, then the business logic to work with said data, finally the GUI that allows the user to invoke the business logic. That is the order I think makes most sense, and has the least chance of failure.

  • User profile image
    spod

    I tend to favour "just enough design" Smiley

    Within my group we tend to favor a less rigid model close to that of Extreme Programming, with rapid iterations over short cycles. It's not formal, and pair-programming isn't done but...

    I think the rapid iteration approach ( analyse,design,implement - repeat ) with the first iteration creating a buildable / installable "product" works well. I've always found requirements are in flux during this stage, and clarify greatly when you build something, and can actually show the customer what you thought they asked for.


    I suppose what i'm saying in answer to the original question is - build them both, many times, but expect to throw away / refactor out a lot of what you build the first time.



  • User profile image
    rampage

    For a database-centric application I try to write a prototype database based on the requirements and then expand the database as the program's needs expand. So, the answer to the question of app first or db first for me is, "yes." Smiley

  • User profile image
    Richard Acton

    ktegels wrote:

    Still, no matter how well and how exhustively we design something, we still find unexpected things turn up. Its the nature of our organization.


    ... Like your customer realising they want something extra or different to the specification you've just spent a day writing up. Anyway, bitching about customers is another thread. Back on topic...

    We design the database structure in Visio first as it will generate the SQL script and provides a nice diagram for the development documentation later on.

    Along side that we'll start planning the objects but design them later. Not always in UML, especially for smaller systems because it just takes too long and customers don't like paying for that time. Deadlines are usually tight too. The code and presentation are then written together from the technical specification document and the objects we have agreed on. (Specifications,designs and code must be QA-ed by another dev before we start work)

    So another vote for database design first.

  • User profile image
    Sabot

    The devil is in the detail people!

    Getting a detailed level of data at a really good focused level of granularity will mean building up the picture by focusing on smaller manageable chunks one at a time, as you can not possibly look at a database as a whole all in one go. It will take many different iterations to get to a level of confidence and other streams of activity working in parrallel (such as prototypes) to search and find the detail you need, but here has to be a point in time when the design must stop and additions or changes are done via a change control process.

    Change Control processing being an agreed mechanism to handle change after design has been agreed and signed off by all parties. These can be small micro-projects that examine the impact of change on a project because it is very important to recognise the impact and subsequent knock on effect to the project as a whole.

  • User profile image
    prog_dotnet

    Microsoft® Solutions Framework (MSF) provides a set of models, principles, and guidelines for designing and developing enterprise solutions in a way that ensures that all elements of a project, such as people, processes, and tools, can be successfully managed. MSF also provides proven practices for planning, designing, developing, and deploying successful enterprise solutions.



    Cover

    Welcome to MCSD Self-Paced Training Kit: Analyzing Requirements and Defining Microsoft .NET Solution Architectures, Exam 70-300. By completing the chapters and the associated activities in this course, you will acquire the knowledge and skills necessary to prepare for the Microsoft Certified Solution Developer (MCSD) Exam 70-300. This self-paced course provides content that supports the skills measured by this exam. Answer the questions at the end of each chapter to review what you have learned and help you prepare more thoroughly. The course also includes solution documents that provide you with examples of the outputs of each phase in the Microsoft Solutions Framework (MSF) development process.

    This book was developed for information technology (IT) professionals who plan to take the related Microsoft Certified Professional exam 70-300, Analyzing Requirements and Defining Microsoft .NET Solution Architectures, as well as IT professionals who design, develop, and implement software solutions for Microsoft Windows–based environments using Microsoft tools and technologies.

    Microsoft Solutions Framework

    http://www.microsoft.com/technet/itsolutions/techguide/msf/default.mspx

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.