The statement that highlights the fundamental disconnect

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!