On 1/26/10 7:58 AM, "Jack Shedd" <[email protected]> wrote:
>> Then don't talk to IMAP. Talk to POP. That's an easy standard. If you're >> going to do IMAP, either do it right or don't do it at all. Half-assed is >> bullshit. > > Both of these statements ignore that existing products don't support IMAP 100% > correctly either. Yes, and that's a problem for them as well. If there was already a perfect IMAP client, Letters would just be an external editor plugin for that client, or a script. > > Obviously, the goal of the project is to be better than other clients, but my > primary point is that focusing, like a laser, > on all the details of IMAP might hamper the effort, and seems to be a sticking > point, at least for you John. It's an IMAP client. If you don't get that right, you have a fundamental failure in your fundamental feature. If that's okay, great, but maybe planning to have a fundamental failure isn't a good thing? > >>>> Yes. But changes now are easier than changes later. >>> >>> Not necessarily. To get started, the group just needs a rough outline of >>> possible problem areas. It does not need to have an absolutely perfect >>> specification document. >>> >>> The best products are built was you go. >> >> Says who. You have absolutely no way to prove that, and no, the plural of >> anecdote is not data. > > I answered your anecdotal philosophy with my own. Software development has > numerous methodologies, and philosophies, all of which have resulted in > completely fantastic products. Personally, the projects I love the most have > clearly been built over time, and with an eye towards constant revision. > > Stating categorically that one way or the other is the ONLY way to get > something done is silly, so I'll withdrawl my comment and submit you consider > the above. Thank you for admitting you personally prefer unplanned code that manages to luck in to getting it done right. Some of us have to support that, and it tends to be a real pain in the ass, especially come security eval time, even if you have the source. "what's this function do?" "how the hell should I know, none of this crap is commented worth a damn, and of course, there's no documentation?" "Nope. I asked, and got told to read the source, it's all in there." Sendmail was particularly evil in that way for a long long time. It worked, but it made you quite insane in the process. > >> Right. Of course. It's always so bloody simple to take an existing code base >> and just make whatever changes you want. Why a child could do it. Hell, I >> have two cats, they should have 1.0 done by Friday, that's how absolutely >> trivial this is. No one in the history of coding has ever found they've >> coded themselves into a corner and now had to make radical fundamental >> changes to get out of it. It's allll magically easy. >> >> Back in reality land, you can't just blindly write code and hope for the >> best. Well, you can if you want hacky crap. If you want to do something that >> will be flexible for the long term, and have a solid, stable code base that >> doesn't have to be shredded every version, you do this 'planning' thing you >> may have heard so much about. > > You're reducing my point to absurdity. As I said, architecture and approach > are important, but absolute definition of all problems, including minor edge > cases, is to me at least, silly. How do you know what an edge case is until you start defining your problem? I mean beyond "I don't like it, so it's an edge case"? -- John C. Welch Writer/Analyst Bynkii.com Mac and other opinions [email protected] _______________________________________________ [email protected] mailing list List help: http://lists.ranchero.com/listinfo.cgi/email-init-ranchero.com
