|
Chris Meech wrote:
I am just blown away that this is the lowest ranked of all. Maybe it's my C and C++ background, but I think memory leaks, resource leaks and the like are all indicators of the quality and usefullness of the code
I agree. But, to me, these aren't inefficient use ...: they're BUGS.
For "inefficient use" I think, for example "to hold a 4KB string into a value passed by copy in a function or to keep a number of copies of that.
Or allocate a 1MByte array just to accomodate a not known number of elements. Or other things like that.
|
|
|
|
|
Navin wrote:
Hard drives are huge, computers have fast processors and lots of memory.
The Software I write is used to somewhat convert data into knowledge.
The data can come in in almost any rate (We have one machine that can produce data with >= 20 MB/sec.
And users are not any more willing to wait. Years ago, colleagues have told me, A run would have been started in the evening and was completed overnight.
Today, customer complain about our program being dead when it is only parsing that 150MB XML-file for a few minutes.
So, to make a point, I dont think efficiency will ever be obsolete.
But we are also using std::vector here, instead of rolling our own that could be marginally faste.
"We trained hard, but it seemed that every time we were beginning to form up into teams we would be reorganised. I was to learn later in life that we tend to meet any new situation by reorganising: and a wonderful method it can be for creating the illusion of progress, while producing confusion, inefficiency and demoralisation."
-- Caius Petronius, Roman Consul, 66 A.D.
|
|
|
|
|
All of the above
Definitely a PEBCAK! (Problem Exists Between Keyboard And Chair)
My First ASP.Net site is now up  http://www.redravenrpg.com
|
|
|
|
|
-And in that order, IMHO:
1: If it is not easy to use, it will likely not be used, and thus not purchased so noone will care how robust or up-to-date it is.
2: If it is not reliable/robust, users will not likely recommend it to others, and will be less likely to purchase the next major release of the product.
3: If it cannot be maintained, users will become unhappy with its feature set, state of [Fixed] bugs, etc.
Just my beliefs on the issue... YMMV.
Although, when you think about it, we continue to use Windows OSes, despite crashes, peformance issues, etc.  
(Actually, they are ALL important; some more than others depending on the scenario.)
Peace!
-=- James (Sonork:100.21837)
[Tip for SUV winter driving survival: "Professional Driver on Closed Course" does not mean "your Dumb Ass on a Public Road"!]
[Get Delete FXP Files Now!]
|
|
|
|
|
I guess the same can be said about other choices, but as long as the code is maintainable,
any part of it can be revised to fit changing needs.
A piece here must be made more easy as a gui standpoint.
A piece there must be made more efficient in terms of ressource use.
Another piece here must be made capable of handling new capabilities.
As long as a project is maintainable, it makes sense to change it
in whatever way is needed to reach whatever goal is required.
That's usually true until the project scope changes or evolves sufficiently from the initial project to become a project that has a different scope or a different intended audience or is otherwise different enough to warrent a redesign - rewrite.
|
|
|
|
|
Best answer so far! This is what professional coding is all about, at least if you expect a product cycle of more than a year.
|
|
|
|
|
The type of app depends a lot on which - for apps where there is little or no competition (and esp. internally developed & used apps), reliability is king - you can suffer through a bad UI and slow response, but if at the end of the day your job is done then all is well. Ease of use is second regardless, and first if you have strong competition. All the other options are important only as they contribute to either Reliability or Ease of Use.
How do you move in a world of fog, That's always changing things?
Makes me wish that i could be a dog, When i see the price that you pay.
|
|
|
|
|
I voted Reliability, although both ease of use and reliability are important, I think in the long run ease of use becomes less important.
This was a tough poll since alot of the things up there are very important to different types of programmers. VB coders and C++ coders do not think alike, hence they may want different things based on the compiler they are using.
Since I am a C++ programmer, I always consider: SPEED, Reliability, Ease of Use as my top three important factors.
|
|
|
|
|
At first glance, you want to vote for all of the attributes listed. I determined my vote by inverting the question:
When it comes down to the crunch, which attribute do you relax your efforts on the least?
In my case, since I do the user interfaces for our products, it has to be ease of use. I didn't choose 'good looking UI', because in my mind 'ease of use' implies 'good looking UI' (but the converse is not necessarily true, as others have observed).
Software Zen: delete this;
|
|
|
|
|
Your application may be fast, easy to use, maintanable, extensible, good-looking, and efficient, but if it's the harderst thing on Earth to install, you won't have a lot of users...
Perl combines all the worst aspects of C and Lisp: a billion different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript. -- Jamie Zawinski
|
|
|
|
|
If your app is easy to use then the users don't tend to worry too much about Speed and Reliability
or a Good looking UI
Michael
But you know when the truth is told,
That you can get what you want or you can just get old,
Your're going to kick off before you even get halfway through.
When will you realise... Vienna waits for you? - "The Stranger," Billy Joel
|
|
|
|
|
Even application is desktop application it can be not easy
inside. Some tasks may be a very complex and as a result it's impossible to do it "Ease of use always".
The good criterion it is level of user's satisfaction but
it is not always mean "ease of use". Many console applications are easy of use but users often are not satisfied because UI. Of course "ease of use" is important but not always.
|
|
|
|
|
Most users do not find console applications to be easy to use. They don't like entering menu selections as numbers rather than simple mouseclicks. They don't like trying to navigate complex hierarchies of menues in a console environment. (I don't, either. It's too slow.)
But ease of use is relative. Extremely complex tasks cannot typically be reduced to a single click, but they can always be implemented with varying degrees of difficulty for the user. Straight-forward implementations will please the customer a lot more than a convoluted one. The challenge is to decide what really constitutes straight-forward.
|
|
|
|
|
Curi0us_George wrote:
Most users do not find console applications to be easy to use. They don't like entering menu selections as numbers rather than simple mouseclicks. They don't like trying to navigate complex hierarchies of menues in a console environment. (I don't, either. It's too slow.)
I work with developing shop system (Point-Of-Sale). The interesting fact that some manufacturers of POS still creates this POSes with MS DOS (for example, Siemens). If it is not suitable and not ease of use why they still do it. In our supermarkets exists a lot systems with Windows created with good UI but what about those wellknown firms that still use MS DOS for it. If console apps. and MS DOS apps. is not ease for use may be they think that ease of use is not so important?
Some times ago I wrote test for thermal printer, our boys from workshop tested these devices for input control. The command line was only number of serial port but in the result app printed some lines and figure on printer and puts some lines on screen with thermal head temperetures that changed during printing. Of course, it can be console app but for the end I created GUI app. with temperature graph. Really boys was satisfied (no need to read numbers and compare it). What is it: ease of use, UI or user's satisfaction?
Speed can be a very important. But not application speed.
I talk about speed of creating new application that is important. We all know what is it competetion.
And it is very important to be first as said old duke thinking about tradition of First Night.
|
|
|
|
|
The best interfaces developed for DOS all emulate a windowed environment. All of the productive ones I've ever seen, at least. At that point, it's got a GUI, and does not qualify as a console application.
|
|
|
|
|
You are right it "does not qualify as a console application. "
But for this POS implemented menu system.
"They don't like entering menu selections as numbers rather than simple mouseclicks. They don't like trying to navigate complex hierarchies of menues in a console environment."
Sometimes even vice versa the system for POS created in Win GUI but like DOS UI.
|
|
|
|
|
Agh. I just realized I misspelled "menus".
I've never seen a well-designed windows application which emulated the console. (Excluding the actual command prompt emulators such as cmd.exe, of course.) Going through a graphical interface with the mouse is typically far faster then going through a console interface, especially at first, before the users really get familiar with the app.
|
|
|
|
|
"But ease of use is relative." This your thought is really good and I absolutely agree with it.
In my opinion it very important to understand what it means "ease of use". I have no notebook but sometimes use it. It is very good and useful thing but I still don't like trackball and every time I connect mouse. Many linux-funs like command line and think that it is really "ease of use".
Another thought - "ease of use" can brake progress. For example one "mad scientist" creates 3D display. Another "mad scientist" creates Mobius band window (or form) so we can see front side of form from all side of display. May be it is will be "ease of use" (or "ease of use" for some people) but may be not. For most people it will not "ease of use" as well as trackball is not "ease of use" for me. And "ease of use" for developer is not the same as "ease of use" for end user.
|
|
|
|
|
"Hey, it doesn't matter if it doesn't work. It's easy to use!"
"Hey, this thing works great! I just have to figure out how to use it!"
Chicken and Egg!
|
|
|
|
|
If it crashes every now and then, then it does matter.
|
|
|
|
|
Simplicity wins. I agree.
At the same time, application must be reliable, otherwise I will look for other application.
Application that is easy to use is likey to have a good UI anyways.
|
|
|
|
|
This poll misses one choice:
the ability to handle the user's needs.
Let's call it 'completeness'
|
|
|
|
|
I believe that would fall under "extensibility" considered the fact that you will NEVER cater for all user's needs in the first or second release...
www.kinkycode.com
[Glossary Manager] [AfterThought Backup Lite]
99 little bugs in the code, 99 little bugs,
Fix 1 bug, recompile....
101 little bugs in the code...
|
|
|
|
|
Just as the title says..
John
|
|
|
|
|
Well, it does depend on the app. Something like a real-time video player really needs more speed than reliability. I don't care if a couple pixels are off on a frame or two, but I do care if the thing takes forever to play and looks like it is in slow motion!
But for many other apps, speed isn't much of an issue compared to reliability.
Remember, even if you win the rat race, you're still a rat.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
