Start In The Middle
coderoom.wordpress.com
coderoom.wordpress.com
The only way I get through boring code it would seem, is by getting paid to slog through it.
This will likely lead to premature aging and an early grave for me...
Luckily, my current side project has someone offering feedback and is interested in turning into a real product. That is the motivation to handle the boring bits.
Of course, I also become bored by these little details. So I wouldn't say it's any better, but it is certainly more fun to work on the interesting bits first.
Hell, I probably wouldn't want to do those last things for money, either!
Customer: I must have anything I want from the database without asking you.
Me, 1 hour later: No problem, here's your screen.
Customer: This only does does Customers. I want to pick any table.
Me, 1 hour later: No problem, now you can pick your table.
Customer: This dumps every column. I want to pick my own.
Me, 1 hour later: No problem. Now you can pick your columns.
Customer: This doesn't sort. I want it to sort.
Me, 1 hour later: No problem. Now you can sort.
Customer: But I want multiple sorts, some ascending, some descending.
Me, 1 hour later: No problem. Sort any way you want.
Customer: It dumps the whole table. I want to filter.
Me, 1 hour later: No problem. Now you can filter.
Customer: It only give me local columns. I want columns from other tables, too.
Me, 5 mins later: Give me an example.
Customer: Here. Give me these linked columns and accumulators, too.
Me, 2 days later: OK. I figured out how to give you all this data too.
Customer: OK. This will work. Why didn't you do all this in the first place?
Stepwise Refinement Method: Time to beta: 1 hour. Time to production: 3 days.
Waterfall Method: Time to beta: not applicable. Time to production: who knows?
I have this problem: I like to start at the edges. One of the biggest hurdles for me when I code is to make myself do the MVP first, then iterate.
Either that or he wondered why he needed to tell you what to do every hour.
It's not missing analysis, it's missing the analysis phase.
Instead of working against human nature by tediously building use cases, data flow diagrams, logic flows, process breakdowns, etc., etc., etc. before doing any development, analysis, design, development, testing, and deployment are tightly coupled in many small iterations. That's the whole point.
That data is used to make a decision, and it's important that developers seek to understand exactly what that decision needs. Your users will often walk their way into a bad solution to their real problem because they will use their (incomplete) understanding of what is available.