Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

When I was assigned a program, I usually build them block by block. For example, I was required to write a program which enable FTP transfer of files, which also allow queueing of transfer and a multi-thread transfer instead of single thread transfer. What I would do is:

1) Try to make the program able to transfer 1 file

2) Try to make the transfer into a queue

3) Try to implement multi-threading

Would you do this instead:

1) Read through all the material/tutorial of all 3 requirement

2) Try to assemble them into a general picture

3) Write the program at once.

What do you think?

share|improve this question
1  
The second one presuppose that you can anticipate all problems you will encounter during dev at conception time. People tend to think they can. They ends up in bloated software with so many useless design in it - just in case - but can't actually anticipate all problems. Small steps, refactoring between each steps, is the key. –  deadalnix Aug 5 '11 at 9:32
add comment

3 Answers

The general answer is: it depends :-)

In most cases, the first approach is fine. This is akin to the Agile method, which works well in many real-life projects. Especially with frequently changing requirements - which is a given in most cases -, there is not much point to try to do Big Design Up Front.

In some cases, the second approach may be better though. I can think of

  • life-critical apps where there is little to no room for experimentation and the requirements must be extremely well defined at the start of the project,
  • performance critical apps where you need to understand the whole picture and design your data structures and algorithms carefully from the start, in order to ensure the needed performance.

Note that there is no wide gap between the two approaches though: Agile projects start by assembling a skeleton system (after just the necessary amount of analysis & design) which is able to something - however simple or trivial - to demonstrate that the system works end to end, then gradually add more functionality. Whereas performance- or life-critical apps, once they have the requirements and design phase done and implemented the (usually much more robust and detailed) skeleton of the system, may also add individual features incrementally (depending on the timeline and resources available).

share|improve this answer
add comment

Albert Einstein

“Make things as simple as possible, but not simpler.”

It's good when you start your program simple and then gradually extend it.
Big projects always begin with something, and with the agile approach I think you're on the right track.

One thing you should make sure of is that you don't depend on the initial simplicity.

Let's have a look at your example.

1) Try to make the program able to transfer 1 file
2) Try to make the transfer into a queue
3) Try to implement multi-threading

During the second iteration, you will be designing the most important classes for the program.
You will be creating abstractions for the files, probably re-doing basic server abstraction from the first iteration, and the transfer manager itself. You will also have to create some kind of GUI that allows to work with multiple files, and tie this frontend with the backend.

After this stage, changing basic API will be hard. Because of that, make sure that you won't have to redesign the whole system at the third iteration. When doing second iteration design, keep things simple and flexible enough (you're in luck when you know what is going to be changed but this is not always the case).

On the practical note, this usually means reducing dependencies with Inversion of Control pattern, interacting with the backend (and inside the backend, too) using interfaces, and separating different pieces of logic into independent modules which can later easily be replaced.

share|improve this answer
add comment

Personally I'd try to do the second method because doing the first way tends to end up with big redesigns to implement the next bit of functionality and meet all the requirements. I think in the end you end up with a better design instead of something cobbled together that isn't coherent but just about works.

share|improve this answer
1  
Except when the requirements change halfway into the project... which, alas, happens quite often in real life. –  Péter Török Aug 5 '11 at 8:50
    
@Péter. I agree that they do change half way through but hopefully your design will be flexible enough to cope with that. When the requirements change your design will either be able to handle them or it wont and neither way of doing things is advantageous in this situation. I see the advantage of agile in getting something out the door quick and getting feedback from that. But I think you often end up delivering code that is a nightmare to maintain because of its self incoherency. –  fwgx Aug 5 '11 at 11:42
1  
my experience differs. All of the legacy projects I have been working on so far were a mess to a varying degree, and none of them had originally been developed using agile methods. OTOH if you try to anticipate all possible changes with your design up front, you still end up with a bloated design, 90% of which will never get used. –  Péter Török Aug 5 '11 at 12:02
    
But that doesn't make agile methods better, it just means upfront design isn't perfect. I think the main problem with agile isn't the "design things as and when needed" part of it - it's that it encourages changing the requirements too much and frequently so that you're bound to end up breaking your design because you're encouraging users to change things. Now they may end up with what they want but to do so it wont be pretty under the hood, by necessity. –  fwgx Aug 5 '11 at 13:00
    
I didn't mean that agile methods were perfect either. But - again, in my experience - they focus strongly on long term maintainability, via unit testing and refactoring. "encourages changing requirements too much" - I can't really interpret this. I have never seen a developer, agile or not, asking its users to change their requirements ;-) –  Péter Török Aug 5 '11 at 14:58
show 1 more comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.