Reality check

Post #236,823 by ben_tilly 12/2/05 12:56:19 AM Reply	Reality check You just said as a universal rule that any step that destroys data must require user notification You said it to a guy who spends a good deal of his life automating batch data processing for very large amounts of data. And you think he is out of line to say that he doesn't ever want to rely on any application that you've designed the UI for. I am far more sympathetic to Barry's position than yours. Like him, I've also had to automate stuff. And I can say from personal experience that if any step has to use a UI designed to make it impossible to avoid notifying the user about critical steps, that step will become the bottleneck that becomes a permanent PITA. Some day I hope that you have to do some serious batch processing. And learn in detail how wrong you were, one failed job at a time. Hopefully with associated midnight wakeups from your pager. In the meantime, try to digest the following clue: there are people whose needs are different than you anticipate. The best way to figure out what those needs are is to listen to them and try to figure out why they are saying what they are saying. That means that you let them tell you their needs, instead of you trying to tell them. Regards, Ben I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)
Post #236,847 by bepatient 12/2/05 9:30:19 AM Reply	The statement that highlights the fundamental disconnect That means that you let them tell you their needs, instead of you trying to tell them. Most here are on one side of this statement, one here is on the other. If you push something hard enough, it will fall over. _{Fudd's First Law of Opposition} [link\|mailto:bepatient@aol.com\|BePatient]
Post #236,906 by broomberg 12/2/05 8:52:21 PM Reply	Devil's advocate mode He believes that he can interview and observe his user population to achieve a true set of requirements. This true set will be the absolute minimum required to do the job. No bells and whistles, minimum flexibility or configurability. Bet there will be a lot of hardcoded values and embedded assumptions. And if those requirements change, then he feels it is OK to start over, and if not start over, change the current code to match the new set of requirements. So, at best he's naive. And at worst, it is a matter of job protection. Either way, it ends up with the same result. A crappy program and an asshole programmer you have to argue with to make changes.
Post #236,930 by hnick 12/3/05 8:33:40 AM Reply	You CAN always leave means to override the default behaviour In the Box example, an admin can globally alias rm="rm -i" which means that rm -rf * will still prompt for deletions. If you really want to blindly kill everyting you have to /bin/rm -rf * Similarly GUI based programs can have command line arguements that cause them to run completely silently. In general, you build your program to suit your clients needs and put in exceptions if you have clients with varying needs. Make it easiest for the majority. This isn't that complicated once analysis has determined who the clients are and what their needs are.
Post #236,971 by tonytib 12/4/05 12:43:16 AM Reply	No, it can be very complicated What if you don't know exactly who your customers are going to be and what they are going to need? For example, let's say you're building a semi-standard product that has to be customized for each customer's product. It has to fit into their assembly lines and match with their standards (for data collection, safety, interface, etc). And the customers are always dreaming up new applications that can be quite different from the original customer. But it's unaffordable to do a separate software control program for each customer. I'll just say there's a reason I like scripting languages. Tony
Post #236,989 by hnick 12/4/05 8:10:02 AM Reply	That's true. Everything for everybody programs are a nightmare that seldom work. As with everything, there are different approachs. Scripting can be good, as can loadable sub programs that can be added or modified later. Being able to modify your program's interface with a configuration file can also work. All have good points and bad points depending on what you are trying to accomplish. There are a lot of ways to skin that cat, and the cat hates them all...
Post #237,023 by drewk 12/4/05 2:20:13 PM Reply	ICLRPD (new thread) Created as new thread #237022 titled [link\|/forums/render/content/show?contentid=237022\|ICLRPD] === Purveyor of Doc Hope's [link\|http://DocHope.com\|fresh-baked dog biscuits and pet treats]. [link\|http://DocHope.com\|http://DocHope.com]

Welcome to IWETHEY!