On Jan 26, 2010, at 6:38 AM, John C. Welch wrote: > You can't have it both ways. If you say it's a mail client that uses IMAP, > you're creating specific expectations about what that client does. > > 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. 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. >>> 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. > 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. > Oh yes. I forgot. Open source excuses all planning and logic. Just fling > code at it. Eventually something will stick. It's just like making > spaghetti. Again, reduction to absurdity. As it's clear this has become pointless, I'll stay out of the conversation. _______________________________________________ [email protected] mailing list List help: http://lists.ranchero.com/listinfo.cgi/email-init-ranchero.com
