From where to start coding a software?

Question

The project which I am going to start is my first project and it is very big. Though it's a great opportunity for me, I don't want me to trapped myself in a messed-code in the end so I have made a whole design of the software (software architecture) divided it into three tiers:

1. Presentation Tier ---- (will be implemented through Java Swing)
2. BusinessLogic Tier -- (will be implemented through EJB technology)
3. DatabaseLayer ------- (will be implemented with the help of Hibernate)

Q1. Which Tier should I select to start with?

I don't have any experience of Standard Product Development environment but I am sure that there is some specific order which is better than other.

Q2. I think that these things come under Good Design Principles and Best Practices. I have searched the internet for these kinds of resources and have found some good resources too but I would be grateful if you recommend me some resources that you know have short, to-the-point and quality content?

Answer 1

"my first project and it is very big"

Please don't do that.

Please do a small project first.

1. Write the "model" (business logic) first. This will be very difficult, since it's your first project. Keep it small and focused on just business logic that you can test and prove that it works.

2. Throw that away.

Now do another project.

1. Write the "model" (business logic) first. Based on lessons learned during the first project this will be much better. This will be hard, since it's your second project. Keep it small and focused on just business logic that you can test and prove that it works.

2. Write the persistence and the object-relational mapping second. Adding database persistence will be very hard, since it's only your first database project, and only your second project.

3. Throw that away.

Now, you have some idea what you're doing. Start a third project.

1. Write the "model" (business logic) first. Based on lessons learned during the first two projects this will be much better. By now, this will still be a lot of work because you finally understand what you're doing. The work, however, will no longer involve technical issues, it will now involve real issues around use cases and what the application actually does.

2. Write the persistence and the object-relational mapping second. Based on lessons learned during the first projects this will be much better. This will still be hard. Nothing makes this easy. It's only your second time, so you'll still make mistakes; there will be fewer mistakes.

3. Write the presentation last. Always.

This is actually the fastest way to do a large project when you don't already know the technology.

Answer 2

Q1. Take a pen and a lot of paper and start designing. That way you make "plans" before writing code.

Q2. Using paper first help designing for quality; regular refinement, refactoring and review help maintaining quality.

Answer 3

There are two approaches to this and both have advantages and disadvantages:

• Top-down
  First develop the UI and implement the data access and buisness logic where required for the UI.

• Bottum-up
  Develop the Database Layer first and then add the UI functionality later.

The first has the advantage that you have a (at least partially) working UI fast which is something the customers like, so it's the de-facto industry standard. The latter one provides a stable and complete Database and business logic layer but they usually have some overhead because it is not clear how the data is later required/accessed.

Answer 4

I think you should start with the business logic layer as this layer should be the one that dictates which functionality the other layers should have. If you start with the data access layer there's a risk that you will end up with a lot of YAGNI code, and furthermore any application should be centered around business logic and not persistence or presentation logic.

You should look into such best practices as DDD and TDD, and you could probably benefit from knowledge about MVVM or similar pattern too.

Answer 5

Design Principles:

Start here http://www.butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

Answer 6

Do the implementation in vertical stripes: implement one capability of the project from the three layer so that the design could be validated from end-to-end.

The database layer could be skipped first, data could either be hard coded, not persisted, or simply store in test files first.

Answer 7

I would add to the existing answers:

Do not use lots of technologies you're unfamiliar with or only have a basic undersyanding; EJB, Hibernate, etc. They give you no appreciation of what's going on under the covers and add to the learning curve, pushing out your deadline. Instead go for something a lot simpler; e.g. RMI client-server application with JDBC or Spring/JDBC for persistence. You can always rework elements later but better to deliver incrementally than not at all.