Good day to you, fresh programmer!

Today you are given your first real programming assignment. So far it was only studying, few dirty data analyses, testing, and documentation tasks. Maybe few non challenging bugs. But now it is different. This is the real deal. This is what you have been prepared for and studying for and you are going to make this first task something beautiful.

OK, so now what?

Now we begin by breaking the big task into several one at a time steps.

1. Mapping

Mapping the problem domain. It is essential to understand the problem and by understand I mean the sum of every possible detail that is known by now to anyone who knows anything about it. Your job is to make a map of all the concepts, needs, and desires for project now and in the visible future. This is not by any mean the design of the task and it is not just understating the requirements. We go deeper and wider than the requirements. We need to know everything. Your software might need to support what the product managers want and also what they don’t know that they want or won’t bother/not skilled to go into such details. But  software is details. You must draw again the map which explains the problem domain even if it was prepared by already. You have to draw it again to make sure everything is clear and to give yourself a chance challenge every bit to pieces.

There are standard tools that can help:

1. Domain analyses  http://en.wikipedia.org/wiki/Domain_analysis
2. Use case diagram http://en.wikipedia.org/wiki/Use_case_diagram

An important remark is that mapping the problem is not equal to designing. The actual design might not be even remotely close the domain analyses. A composition connection for example might be transformed into a class with members into it. Although the end design might be just that it is important at this stage to view this connection as an abstract idea of a system which is strongly coupled and not as  a shorthand to better documented software which is a result of using code generations tools.

2. Breaking

Breaking into separated responsibility areas. It is impossible to find a god solution just by treating the task as one. It must be break down into as independent as possible pieces. Divide et impera. The paradox is that the whole can only be visible after all the parts are removed and ordered. So, before even begging taking moving to design it is essential to know what the software parts it contains. Check out the separation of concern concept: http://en.wikipedia.org/wiki/Separation_of_concerns. This is an OOD concept but it also apply to the analyzing domain.

3. Evaluating

Now that you know the problem domain well and you have some idea of responsibility areas it is time to begin the evaluation. At this stage it is important to bring as much solution options as possible and to evaluate each. How the evaluation is done? I suppose that there is more than some personal preference and experience involve. The import thins is to actually do the evolution. More often than not the first solution is taken when a much better one was there just across the corner all the time. The evaluation can take into consideration the complexity, risks, skill set and time frames. Kasporov, the chess master is evaluating chess setup with material, time and quality terms. Those terms and others can be applied to software evaluation.

4. Planning

Planning before designing? I know it sounds odd but design also needs planning. Have you heard of over design? Most of software management systems today have adopted the iterative concept. Instead of everything designed, written and tested at once the progress is instead done in several iterations. Each phase includes mini designing, writing and testing where the idea is always to stayed focus and to avoid spending too much energy where there are not needed.