

Start In The Middle - s3b
http://coderoom.wordpress.com/2010/05/18/start-in-the-middle/

======
agentultra
My hard-drive is littered with projects where I did tackle the cool bits
first. It's how I work. Most of them aren't finished though because I lose
interest when I hit the boring bits.

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...

~~~
bockris
I started to write this exact comment this morning and then got distracted.
Upvote for you.

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.

------
Zepalesque
Ironically, I started reading this article in the middle, got to the end and
then read the top half.

------
fleaflicker
often the sum of all the boring bits is what distinguishes your product.

------
ibagrak
Can't say that I've abandoned that many projects due to distraction of
starting from scratch... I just haven't started that many, but I mostly agree
with this line of thinking. I think programmers (myself included) tend to get
distracted by optimizations and minutia which actually have no bearing on
project/product success. That makes the boring, routine part much longer than
it needs to be.

------
tjmaxal
This is exactly why I switch hobbies every few months. You spend so much time
learning to do the thing before you actually try it. Like kayaking, or rock
climbing, then you figure out that once you know what you are doing it just
becomes repetitive. I wish there was a to just jump past the learning curve to
experience things before you learn how to do them.

------
edw519
I love how everything has a fancy name now. We've been doing StartInTheMiddle
/ MinimumViableProduct / Prototyping / GetSomethingOut / StepwiseRefinement
for years:

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?

~~~
barrkel
The problem with the approach you just described is that it's missing
analysis. You got a list of features, not use cases. Maybe the customer wanted
to solve a particular problem, but the only way they got to elucidate it was
in terms of incremental functionality. Better than the wrong thing, but not
the way to delight your customer either, I bet.

~~~
edw519
_The problem with the approach you just described is that it's missing
analysis._

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.

~~~
barrkel
No, I'm not talking about an analysis phase in a waterfall development. I'm
talking about the blindness you can get when you're incrementally developing
at the level of features, when you can no longer see the bigger goals.

~~~
dagheti
The key question is "Why" that needs to be asked. A customer may think they
want to sort, select, and aggregate the data, but fundamentally "get the data"
is very rarely the real reason for doing something.

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.

------
RyanMcGreal
I absolutely concur, at least with respect to my own motivations and habits.
Every successful project I've built started in the middle; whereas every
abandoned project started with grandiose organizational plans.

