This is a huge issue especially in the current economic downturn as everybody is looking for the best deal in town! Well with application/database development the best deal in town is not the one with the lowest dollar amount. Rather it’s the one that has feasible and reasonable cost estimates and more importantly with the right group of developers. The truth is when you go out to look for a company to do an application that your business depends on, before you sign that contract and pay the deposit, make sure the company can do what it promises. Check their references and find out if they have a history of commitment to their clients. It’s easy to say that we can do it and also we can do it in a required time frame. Remember that once you pay the deposit, you are hooked.

Naturally companies that send their work overseas will have the lowest costs. But unless you get extremely lucky (and in all these years, I have almost never seen that happen), you could be taken for a ride. You will be out of your money and your project will take 5-6 times the time it may take to finish here. Sure, in the beginning the cost is very attractive but then as your project goes on, you will see promises not coming thru and excuses come one fter another. And most of the time you are lucky if the project even ends. In many cases that I have seen at best overseas companies complete about 90% of the job and then you will be here looking for a company to do that last 10% only to find out that this 10% may cost you more than the 90%! Why? Because working on existing code is generally extremely difficult. You will have to pay for the new company’s learning curve and then how do you know that the code coming from overseas is well documented. Then also, After everything is complete, you will have the two companies blaming each other for any problems. Now after several years a project that should have completed in six months, is taking you about three years to finish and you have paid the same amount that you would have to pay if you had done it all locally.  That’s as I said, if you are lucky!

Also remember that with complicated enterprise database applications, you have to have quick access to developers. Sometimes it may take several meetings to get one single requirement understood. Just imagine how that would work with an offshore company with different time zones, language barrier, etc.

Do your homework. Know who you are dealing with. Check references and make sure the scope outlined in the proposal is complete.

Creating objects that encapsulate all necessary data elements of an entity is a great way to modularize your application.  Let’s think for example of an application you are writing for a university.  You have three main entities: Students, Classes and Faculty.  If I were to build such an application, I would create a class for each entity that would hold all possible data elements for that entity.  That includes data that your application doesn’t currently require.  For instance, in the Student class the city that the student was born in may not be of significance right now.  But still when you create the class, you should still allocate a space for the city of birth just in case it becomes important for future statistical purposes.  In such a case, instead of having an application programmer go into the class code and adding new functionality, the front end programmer can just pull the city of birth using a Get function.

You have identified the data items that you want to save and you know what data you want displayed on each page.  Which do you do first, User Interface design or Database Design?

That might be a matter of preference.  What I normally do is create my database tables first.  It’s easier to make changes to your database table structure than it is to change how data looks on the screen.  Screen changes do take longer usually.

MS-SQL has made designing tables so much easier.  You can even use the SQL script builder to insert into and update your tables.  Writing Stored Procedures is always the preferred way to save and retrieve date.  A convenient way to call the stored procedures would be from data access classes.  You generally encapsulate your data access routines into these classes.  Then from your front-end application, you would call the class methods.   This way you would organize your application.

1. User Interface Design
2. Database Design

Designing the User Interface.

Based on your blue print you should know what you want to present.

Put related information close to each other.   Data on the page needs to be related and although it may need to be saved in a few different database tables, needs to be interconnected.

Navigation from page to page needs to be made as easy as possible. If application’s web pages are required to have common headings, master pages will become handy.

However you decide to do your user interface, you will need to use a tool like the .NET environment.  .NET environment will let you design your screen the way it makes sense to users.  You will design your pages and then code the application so you can save screen data in your database.

The general advice would be to try to use a consistent way to save and retrieve your data so the job of replicating the same process would be easier.

Identifying the need

1. Conducting meetings with requesting organizations to define in clear terms what needs to be accomplished.
2. Creating a blue print of the final product.
3. Refining the final product by reviewing the blue print with the requesting organization.

Keep in mind that these facts about the blue print:

• While bullet points show the major idea, details may not cover 100% of what is needed.  This is just a fact of life.  Project definitions that try to define every minute detail, often times will take more time than necessary and will result in unwanted delays.  With that said, major points do need to be identified.
• When a project is being defined, requesting managers should always talk about the big picture, what is in the horizon and how the product of this application development project fits within the future of the organization.
• It’s important to conduct meetings with different people within the requesting organization to learn about other viewpoints and expectations about what need to be accomplished.

Next I will talk about:

User interface design

Database design and development.

Platform to use

Finding an application development team.

I would say it’s time for you to upgrade your database management ways.  So where do you find database designers/developers?  How much should it cost you? 

People have different ways of finding their resources but as far as the cost is concerned, don’t think of it as going out there to buy a nice Appliance for your house.  Instead, in terms of cost, think along the line of remodeling your kitchen.   Database development is not cheap.  Even if you get a cheap offer say from offshore companies or some local recent graduates, don’t be duped into starting with them.  It will be hard to get out of it.  And when you do, most probably the new company will have to start from scratch.  You have lost several months and thousands of dollars, you are frustrated and you are still without a workable database.

The invaluable advantage of hiring a professional US company is that during the course of database development you will need to be constant contact with your developers.  They need to learn your business inside and out!  You will become very good friends with them so they will need to be easily accessible.   In fact before you hire them make sure they understand your business well and that you are comfortable with them. 

I used to hear that Microsoft and Oracle database experts charge something in the neighborhood of $400-500 per hour!  That’s a whopping figure but it should tell you that if you find a good database developer for under $150/hour don’t let them get away.

Now if you are new to this, I don’t want to scare you!  If you are just starting your business or have minimal amounts of data, your costs will be much lower depending on what you want to do with the data.

The problem with triggers is that you tend to forget them!  Suppose after a table has been designed and used for many months or years, you decide to write a new script (i.e. stored procedure) to change something that affects one of the tables that your trigger changes, you will have to remember about that trigger!  Or it could come back to haunt you.  And then after the trigger damage is done, you will have to edit your trigger to make its functionalities conditional.  Over time, with so many conditions, your trigger will be way too confusing and the whole original purpose of creating the trigger diminishes.

Use triggers with care.   I think delete triggers are generally safe, insert triggers are fairly safe as well.  Most problems are with update triggers.  I would try to avoid them.

At AMK Web, we recently experienced this in its worst form. Is it even possible to account for all cases? And if you ever do, how does all your error checking impact the speed of the process?
Our solution was that since we are dealing with huge amounts of data, to keep our client happy with the bill, we decided to break the data down into chunks so that we can deal with small amounts of it at a time hence making the exception handling process more manageable and faster to code.