Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Start In The Middle

coderoom.wordpress.com

Post reply on HN
Print view View original

11–18 of 18 posts

Re: Start In The Middle

#11

Post by arbitraryperson »

agentultra wrote: post #2

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

Same here. I was kind of confused as to why anyone would start a project and think, first, "Well, we need a user registration system."

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.

Re: Start In The Middle

#13

Post by zsouthboy »

agentultra wrote: post #2

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

I do exactly the same thing. So many projects I've finished to 80%, because I got the thing I set out to do achieved. That final 20% is documenting, finishing a UI, etc - and I'm not forcing myself to do (in my mind, the difficulty level) trivial, uninteresting things.

Hell, I probably wouldn't want to do those last things for money, either!

Re: Start In The Middle

#14

Post by barrkel »

edw519 wrote: post #4

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

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.

Re: Start In The Middle

#15

Post by edw519 »

barrkel wrote: post #14
edw519 wrote: post #4

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

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.

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.

Re: Start In The Middle

#16

Post by barrkel »

edw519 wrote: post #15
barrkel wrote: post #14

Earlier quoted context omitted.

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.

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'…

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.

Re: Start In The Middle

#17

Post by randallsquared »

alec wrote: post #10
ihodes wrote: post #8

Earlier quoted context omitted.

Not only that, but I'd imagine your customer felt more involved in the process and felt she had more ownership of the project because of it. 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.

"I'd imagine your customer felt more involved in the process and felt she had more ownership of the project because of it." Either that or he wondered why he needed to tell you what to do every hour.

Indeed. When I ran a small-business software shop, the customers hardly ever were willing to spend enough time explaining what they wanted, because they couldn't imagine anything but what they wanted, and viewed having to specify it as some sort of attempt on our part to get out of doing something. Customers want to give a short summary of what they want, and then be pleasantly surprised by the great customized product they get in return. Once in a while, that even happens.

Re: Start In The Middle

#18

Post by dagheti »

barrkel wrote: post #16
edw519 wrote: post #15

Earlier quoted context omitted.

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'…

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.

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.

Post reply on HN