This is an attempt to define some of the computer software application develeopment principles. The principles and methods defined in this document are an accumulation over long years of application develeopment efforts. Some advices may not seem to fit for large organisations or application development consulting companies. Some may seem to be like jokes but whether you follow wellknown methodologies or not, whether you create and stick to big project plans or not, has nothing to do with the simple bits of advices listed in the following pages. You can still perfectly watch your companies standarts and methodologies while practicing the following rules of thumb.

I believe that implementing project plans and methodologies may well help you on your way of developing big computer software application projects but they will never make your applications better than those if you hadn't implement them at all.

Furthermore, application develeopment tools, be visual, or case, or modelling tools etc, although may provide great help in applications development cycle but this doesn't necessarily mean that they will help you create good applications.

Some basic principles or ideas are :

• Be practical. Never get involved in project plans and methodologies to a great extent. There is nothing magic to expect from them that will make you create better applications. They will only make better the coordination and your application development cycle.
• Try to reuse. Reusing parts of your application is one of the magics that will allow you to create better applications even if they are not so good in the beginning. With reuse you will be able to improve the quality of your software very quickly.
• Develop components. Components will help you in reuse. Do your applications business analysis in such a way as to identify components and develop them first. Develeop subtrasactional methods and then transactional methods, if needed. Once you have developed your components you can start building the application that the user wants to see by making use of these and previously developed component methods.
• Try to separate your data access from your business logic. The data may change but it should have less impact on the business logic. The business logic is the part of your application that will change a lot but so it should not have a lot of data logic in it. Components will help you in the separation of the two logics.
• ...
• ...

Now into some more details :

	Design of your data
	Building components
	Example
	A guideline PPT document-in Turkish (You can click to view or download by right click and then "Save as..")