<div><div><br>Jer wrote: <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">A Factory is significantly more than a basic crawler, it is
<br>responsible to "understand" the content in as much of a human context
<br>as possible, and the closer it gets the better knuggets it can mine<br>out of that content. That's not easy, today or tomorrow.</blockquote><div><br>Okay - could you draw a clearer (for me at least) line between where a factory ends and a collector begins?
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>> Let's define the requirements first (like any good project, eh?
<br>> Define the requirements then match potential solutions against the<br>> requirements).<br><br>That's not my bag, I'm very much let's build it first and learn/adapt<br>as we go. Requirements are for when you are afraid of change, not
<br>embracing it :)</blockquote><div><br><br>Sorry, I'm too steeped in process analysis (business, not programming) and project management to let go of this one. Requirements are for when you want to have the least rework possible - this is not the same as being afraid of change. A further, very pragmatic reason for defining requirements early on is that once you have built something, you are very unlikely to be willing to go back and rebuild the whole thing differently. I'm very much into the software paradigm that says "release early, release often" but I disagree with "Plan to throw one away; you will, anyhow." Especially when you're writing a framework/specification upon which others may be basing a great deal of code.
<br><br>I believe very firmly that the idea that investing more time in planning to reduce time in rework later is a *very* appropriate value in the context of creating a framework upon with other work will be based. The cleanest, most open, and most visionary framework possible will also be the most attractive and compelling framework possible. You know how you feel when you seen an elegant solution in code? The framework is much more important than code, and it should also be that elegant so that when you tell people, "it works this way" and show them, they go, "Ah - I see - that's beautiful!"
<br><br>Best Regards,<br>Aerik<br> </div><a href="http://lists.wikia.com/mailman/listinfo/atlas-l" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"></a>-- <br></div><a href="http://www.wikidweb.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://www.wikidweb.com</a> - the Wiki Directory of the Web