Thomas Abraham (11/7/2013)
bryanellis (11/7/2013)
This reminds me of a programming test I had when in college. The professor gave us a single task: get the top 10 student names alphabetically from the college database. The database was in an unsorted text file and we had to use assembler language. I asked a simple question "Does efficiency count?" to which he responded "No". I promptly left the classroom for the computer lab. 30 minutes later I had the 10 names by running through the list 10 times. While extremely inefficient it gave the answer to the problem. I went back to the classroom and found the professor still lecturing the rest of the students on how to build a merge sort. To my knowledge I was the only one to finish the test in the class period. Many times a business user just needs an answer, not always a solution that can be repeated efficiently in the future.Bet you could have found it by visually scanning the list in 10 minutes or less. Why did you waste 20 minutes?
I'm not picking on this particular poster. This was just the most concrete example of the "hurry it up" at all costs mentality I run into a lot.
I agree with other posters that "it depends". However, slapped together solutions have an annoying habit of living longer than intended. Maintenance costs eat resources.
If I'm doing an ad hoc query, I tend to go for the quick solution, still being mindful of the load I might put on the server.
For anything that gets saved to be rerun, I slow down and try to get it right the first time. Do I always look at the execution plan to squeeze out every inefficiency? No. But I try to be more clever than I would for an ad hoc query. I might be stuck maintaining the beast I created for a long time.
Corners have to be cut on almost every project. But, be careful before you cut.
At college one of the courses I took was split into two halves; one half for those interested in software engineering and the other in business analysis and management. There was plenty of joint modules and everyone seemed to have a leaning one way or the other (and we all - almost all - excelled at times at looked rather foolish at others.
This one girl (for we were all kids then) leaned towards the BA/Management side and struggled with programming. She wasn't stupid at all but programming was not for her. When tasked with printing the alphabet in reverse (in Ada, if I recall correctly) she hardcoded the printing of the alphabet in reverse. She did technically fulfil the task, however, it was part of a module that clearly was to do with looping. I feel that she was too smart to know what she did was what was truly asked of her but didn't have the confidence to pursue one that did.
My point is that a software delivery still needs maintainable for its foreseeable lifetime and performant enough to be usable. Any UI must be reasonably intuitive. It doesn't need to be perfect but it should be developed properly in the context of intended use.
In my anecdote the intended lifetime needed zero maintainability, UI was irrelevant and performance was not an issue but the key requirement of the software was not met (i.e. to demonstrate a technique) so it was a failure. PS I think she did at least OK on the course and has probably been successful in her career - just unlikely as a developer.
Oh and Steve, "a little clunky"? Intentional provocation Mr Editor?
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!