Approach to a programming task

Question

All,

Given a problem statement, when I start of with the analysis and design, I tend to think too much about the various functionalities associated with the task (sometimes not even mentioned in the task). My point is, I get diverted from the main task at hand thinking about various scenarios that I should consider while coding and this tends to demotivate me because I am often very confused in the end. What approach should I take in this case since thinking a lot on all possible scenarios comes naturally and I only try hard not to.

Answer 1

What you appear to be describing is a problem in defining your scope. My advise is as follows:

1. By all means think about all the different possible tasks, you may well come up with some useful additional features. Write headings for all the different ideas you've had, but nothing more than headings.

2. Review and prioritise the headings. Some at the bottom can probably be lost, concentrate on the functionality requested.

3. Expand the top headings into their sub-tasks until you have tasks that are only a few hours or days long each.

4. Review these with the person requesting the change (possibly before expanding the detail if the person is non-technical).

5. Begin work on the top task and continue downwards, producing prototypes and demonstrations (if not releases) at regular intervals for review with the requester.

6. Add to and review your task list between task completions; more tasks will always result from user reviews, and some may become obsolete.

Answer 2

Instead of thinking about everything at once, use a top-down approach.

So think: 'what does this program do on the highest level possible?'

Example: if you're writing a piece of code to take a string array and manipulate each string somehow, you'd code this first:

public ICollection<string> DoHighLevelStuff(ICollection<string> items)
{
    for(int i=0; i<items.Count; ++i)
        item = DoLowLevelStuff(item);

    return items;
}

and worry about exactly how the lower-level methods work later.

I take this approach naturally, but some people can't help doing the opposite.

Note: different problems require different approaches and a bottom-up approach is not neccessarily poor practice.

Answer 3

I would very strongly advise you to have a good look at Test Driven Design.

Here you start with writing a test for each new piece of functionality. The word "test" here indicates that you test the behaviour of the code by checking if it works as you expect. By writing the test first, you are guaranteed that you start by thinking in how to use your code, instead of how to write it. You then implement enough to make the test pass - i.e. fulfill the requirements, and then add more tests describing more functionality, and more code to make it pass. Repeat until you have all the functionality you need.

I would suggest having a look at http://junit.sourceforge.net/doc/testinfected/testing.htm which describes how to develop a Money class in this way.

I have found the approach VERY helpful especially for libraries. You might too.

Answer 4

You can try thinking in small increments and writing stuff down at each stage.

Start with a requirements document. Think from the end user's perspective. Freeze the requirements. Most importantly write it down in a version controlled document.

Then move on to the functional specification. Think from an architect's perspective. Write down in a separate version controlled document, how each of the requirements will be met. It should describe all user interaction and functionality.

Now move on to the design document. Think from a lead's perspective. Write down the high level design document. This should describe high level modules and clearly spell out the interfaces between the modules. The interfaces must be frozen at this stage.

Now start actual coding. Think from a programmer's perspective. Implement module by module. Focus on one module at a time. Stop coding a module once it adheres to the already frozen interface.

If all goes well, integration shouldn't be too painful.