| 1 |
>> The only advice I've got is to do things in increments as small as |
| 2 |
>> possible. Don't do "big bang" integration. Make sure there is a |
| 3 |
>> runnable testable program after the first week of development. Maybe |
| 4 |
>> it doesn't implement any significant features, but you must have |
| 5 |
>> something runnable and testable at all times. Otherwise, you can get |
| 6 |
>> too far down the wrong road before you finally figure out that either |
| 7 |
>> a) what you specified isn't going to work, or b) they didn't |
| 8 |
>> understand the specification at all. |
| 9 |
> |
| 10 |
> ACK. And another important tip: split your big problem into smaller |
| 11 |
> and smaller generic sub-problems. Then you'll have great chance to |
| 12 |
> reuse an existing package or let some contractor develop/adapt one |
| 13 |
> without telling him about your actual project. |
| 14 |
> |
| 15 |
> Movie tip: "The Cube" ;-) |
| 16 |
|
| 17 |
That's a good movie and a very appropriate recommendation. I think a |
| 18 |
lot of people are saying that when it comes time to execute a plan |
| 19 |
like that, it gets fouled up because the spec is hard to write and |
| 20 |
it's hard for coders to test what they've written. |
| 21 |
|
| 22 |
- Grant |
Archives