What makes a good program great? 2

[northernbeaver]

If you ask any programmer if they write good programs they will all tell you "yes". So as a community I pose this question; what makes a good program great? When you look at developing a program what key elements have to be there? How important are these elements? Now I know people are going to yell at me as each program and system will have different priorities so let’s try to keep away from specifics for now and focus general elements.

In my humble opinion I feel the following items have to be there to make a good program great:

1) Accurate Data Collection-It seems obvious but I think worth mentioning. a program has to have the ability to collect data accurately which will encompass the ideas of troubleshooting user input making sure it is correct and storing the collected information in a way that makes outputting easy and effective

2) Ease of navigation: using the program has to be quick, efficient and set up in a logical way that duplicated the process each user follows in the system lifecycle.

3) Growth and adaptability: I find it hard to separate these two as you can’t really have one without the other. A program has to be designed with not only the systems current requirements but the ability to grow and adapt to changing needs.

These are the top three that I can think of. Do you agree? Disagree? Feel I left out something important? Let us as a community of professionals try to flesh out this list and perhaps answer the question "What makes a good program great?"

 

[LesleyW]

I'd rename your number 2 item to "Intuitive user interface" because user interface is bigger than just navigation.

Hmm, I wondering if "Well documented" should be in there.. I'll throw it in as a suggestion.

I guess as we're in the OOP forum, some reference to reflecting the users' reality should be in there.

 

[northernbeaver]

Ok new list we got;

1) Accurate Data Collection-It seems obvious but I think worth mentioning. a program has to have the ability to collect data accurately which will encompass the ideas of troubleshooting user input making sure it is correct and storing the collected information in a way that makes outputting easy and effective

2) Intuitive User Interface: using the program has to be quick, efficient and set up in a logical way that duplicated the process each user follows in the system lifecycle.

3) Growth and adaptability: I find it hard to separate these two as you can’t really have one without the other. A program has to be designed with not only the systems current requirements but the ability to grow and adapt to changing needs.

4)Well Documented: A program should be well documented to decrease developement time -multiple programmers in there at one time, etc


what else do we have?

 

[SQLSister]

Really solid error checking and handling

Questions about posting. See faq183-874

 

[stefanwagner]

Well - as allways, it depends.
A programm with a very well defined scope may not need to change and grow.

The last modification to 'bc', which is a gread calculator, was made 4 years ago. Since there are no new numbers or operators invented - why should it grow?
Some of the greatest programs are build in the right size from beginning, and don't need growth.

If someone would vote for eclipse - this has to evolve when java evolves from 1.4 to 5.0. So you have to decide from case to case, whether an attribut is needed, to make a program great.

It has to be solid.
It might terminate on div/0, but shouldn't core-dump.

It should scale well and not leak memory.

It shall depend on as less as possible, and the dependencies should be clear and straight.

It has to do its job accurate.

It has to be performant - performant enough to get the job done.

I'm not sure whether Lesley talked about a user-documentation, or a developer-documentation.

seeking a job as java-programmer in Berlin:

http://home.arcor.de/hirnstrom/bewerbung

 

[Zech]

Are you referring about the software being great from the users or the programmers' perspectives? Because programmers and users may not share the same values of what they consider as being a great program.

From users' point of view, a great program is a program that ...[ol]
[li]conveniently and reliably solves the users' problems. [/li]
[li]has less learning curve. Try to keep your program having similar interface as much as possible to existing programs that users are accustomed to.[/li]
[li]does not hinders / limits the users. Always remember that users most likely run other programs while using your software (so don't make your program a resource hog). Also, users may use your program in conjunction with other existing programs (eg. exporting your program's output to excel spreadsheet or existing database system). Thus, sticking to common protocols and data format is generally a good practice.[/li]
[li]Always assumes that computers are dumb. Always create an avenue for users to verify/audit/fix the integrity of the program's data and consistency.[/li]
[li]has someone / company to contact to, in case if things have gone horribly wrong. Good documentation does not solve all the problems and therefore, putting your contact info and providing good support for the software is a good practice.[/li]
[/ol]

From programmers' point of view, a good program is one that ... [ol]
[li]is well-designed. Reusability, Extensibility, and Clarity. They often mean less future work for the programmers.[/li]
[li]elegantly solves a problem. This kinda reminds me of one of the winners during the 'Core Wars' heyday. One of the winners had only three lines of assembly codes. It was a brilliantly simple solution that somehow was unthinkable to other competitors. That simple program easily wiped out other more sophisticated competitors in the game.[/li]
[li]is robust. No bugs mean less work for programmers.[/li]
[li]Always assume that users and computers are dumb. So provide a mechanism to deal with users tampering the program and data's integrity. Also, computer glitches do happen, so be prepared to deal with that as well.[/li]
[/ol]

 

[fumei]

I agree with the last post. However, I do not think users #1 is any different from Programmers #1.

A program does something. A program that is programatically well designed (fully Reusable, Extensibile and Clear) but does not solve the user's problems...is still a bad program.

We have huge programs, hundreds of thousands of lines of code. The programmers think it is great. They have never spoken to end users. The end users hate it, because...simply, it does NOT do what they need it to do, in order to do their job.

We have 900 full-time application developers. I took a object oriented design course with some of them. ALL of them told the instructor that they had no time to do design work - they are paid to code. The instructor told them - then you will write bad code. I could not agree more. In one exercise we were asked to write out a code snippet. My lab partner took the 45 minutes using elaborate CASE tools to come up with something I wrote on paper in three lines. In another exercise, the instructor gave a scenario of a program and asked - how many objects are needed to do this. Every single one of the programmer had it wrong. They ranged from four to 20 objects they thuoght were needed. The answer was one.

Sorry for the rant, but what makes a great program is - does it clearly do what it is asked to do. That little statement means:

1. finding out, really finding out what it is supposed to do

2. coding it to do that, with as little code as possible

Programmers that build "extras" because THEY think it is cool, are not building great programs. Programs have users - otherwise it is essentially useless. There is a botton line, where the rubber meets the road. If the person who actually uses it feels reluctance, and cringes whenever they use it, I don't care how elegant, reuseable the programming is...the program sucks.

Gerry

 

[northernbeaver]

I find it really amazing the difference between everyone’s answers as well there is a common theme between them all. We believe we know what is best; best for the system, best for those “dumb” users, etc. As a community of programmers we sometimes miss the big picture as we tend to be detail oriented people. We try to be software engineers at the same time being programmers, trying to think like “dumb” users. I know I can fall into the idea that “the programmer knows best” phsycology which just isn’t true in most cases. We can write the slickest software on the planet but if it doesn’t match how the users do business or is uncomfortable for the user to use then the program is no good.

I think users have to be in our forethoughts when we sit down to program; error handling, how to make the program and user work together for optimum performance, etc. efficient code is, of course, very important which I think we can all agree on. Memory leaks, bad network lag, or endless processes will diminish a programs use-ability. I think we have to include process errors in this as well. If the program doesn’t track the information life cycle properly then it has a problem.

A programs compatibility with other programs is a point made by Zech that I had never considered, to be honest, and I’m glad it was brought to my attention. There is no point in re-inventing the wheel unless we plan on improving it. So sticking to standards so our data/program is compatible with other software bundles will increase our own programs value.

I used the term growth and stefanwagner pointed out that not all programs need to grow. So far in my experience that there are not many companies/ industries out there that there process stays the same forever. Business changes, Industries change, and times change. New technology these days is popping up almost on an hourly basis. That’s why I feel that programs need to be able to adapt to changing needs as the information lifecycle the program was originally designed around may change. Having an adaptable software program will increase the value of it to the user which in turn makes it a great program.

So as a bit of a recap then what I have taken from the postings so far is this;
1. Intuitive User Interface
2. Really solid error checking and handling
3. program and process adaptability
4. Compatible with standard programs/practices
5. Information life cycle/process aware program

The question also has to be asked “Why don’t all great programs succeed?” lets face it half of Microsoft’s programs don’t match these criteria.

 

[stefanwagner]

There are a lot of basic tools in linux, where every growing might be a big problem, like sed, tr, less, ...
These are used so much in scripts, that every change could break existing scripts.
Since they aren't used only in linux, but in a lot of unices, a change is nearly impossible.

An OS-update mostly independent from application-updates. So you can't say: 'This is bc-2003, use it with unix-2003'.
You can't and you needn't.
This environment teaches the developers to create clean and stable interfaces.

These tools are very atomic in their responsibility.
The do a clear and tiny job very well.
A small tree might spend cooling shadow for a house, but when it grows, it might become a danger for the house.
---
Often the ambitions get in conflict to each other.
Look at 1.: Intuitive User interface. - 4.: standard practices.

I thought about capitalization in menus.
It was not an academic kind of "let's think about menus today", but I started using a new mail-client, and allways had to search for the 'delete mail'-entry.
I looked into the right menu, but it was written 'Delete Mail'.
I guess I read the term 'delete' about 10 times per day, but in most cases, it's written in lowercase.
So when I open the menu, I don't see 'delete' immediately, while I see 'Options' in the 'Tool'-menu without delay.
The human brain is very fast in pattern-recoginition, but 'Delete' isn't the expected pattern.
While we germans write subjects capitalized, and have a word 'Option' (and 'Optionen' [pl.]) - I see this one immediately.

Of course, after using the program more often, I blindly go to the last entry in the context-menu, and delete that mail. But not every command can be the last entry.

My point is: The intuitive way would be to use only lowercase letters - if the used expressions isn't like 'HTTP' or 'TCP'.
But the standard is the other way. I recognized that nearly every program uses capitalized keywords.

When I used ms-word, I didn't find 'Print-Preview' in the View-Menu, and 'Page Format' where the other format-commands where, but both in the 'File'-Menu.
Misguided developers adopt this de facto standard, and cement it in their applications.

Are we forced to repeat an error, because it became a pseudo standard?

seeking a job as java-programmer in Berlin:

http://home.arcor.de/hirnstrom/bewerbung

 

[Zech]

“Why don’t all great programs succeed?”

Engineering is a different matter from Marketing. Just because a program is well-engineered, it doesn't mean that the program will sell well.

That is where user training, software support, documentation, etc. should come in.

I would classify Microsoft as a great marketing company than an engineering company. Microsoft manages to be what it is right now due to its marketing strategy rather than engineering feat.

 

[fumei]

Great big agreement with Zech. Marketing succeeds. If I may rant some more.

I am an artist in one of my incarnations. I use computer graphics programs to help do design for paintings. I have been doing this a long time (since 1971, but on mainframes then). There was a GREAT program that came out in, I think 1991, called Fauve Matisse. Fabulous interface, natural brushes etc etc.

I still use it. It was designed to run with 8 Mb of RAM, with a best RAM as.....16 Mb. Think of how this thing runs with 1 Gb. badda bing, badda boom.

Anyway. I have taught numerous people how to do sophisticated graphics manipulation, as well as original creations, using Matisse in 30 minutes. I mean - they can create, modify images to a equivalent moderate/intermediate Photoshop level IN 30 MINUTES. This is from scratch, never having used it before. Try doing that with Photoshop. 30 minutes with Photoshop, starting from scratch, never having used it? You would be lost.

PLUS, Matisse can do things Photoshop can not do. In Matisse, if you can see it, even if "it" is a single pixel 20 layers down, you can click on it and do whatever. It is fully object oriented.

The interface is completely visual and intuitive. I have taught a four year old to do textured cloning between images in under 5 minutes.

Matisse was bought by Macromedia, who killed it in order to promote XRes, their (at the time) competition to Photoshop. XRes is long dead now too. But I still use Matisse (although of course I also use Photoshop....).

A great program, by the definitions posted here. Robust and a joy to use. Dead. Marketing (because Macromedia wanted their own products to "succeed") killed it.

BTW: as license is long gone, the company is long gone, I give away free copies of Matisse to anyone who wants it. Full colour version with license key. But what I would really like is someone really, really good at hacking. I would love to be able to poke around inside Matisse and see how the heck they DID that.

Anyway, to shut myself up....some of Microsoft applications are good, bordering on great. Bloated to a outrageous level, mind you. Just remember this though, the ONLY reason Office products work as efficiently as they do is that Office apps do not use the amount of API as everyone else is forced to use. Microsoft apps can, and do, have their own communication to the OS. Everyone else has to use API. If MS Word had to use the same communication as every other word processor is forced to use....it would NOT be a best seller. No one would buy it because it would be so ssslllloooooooooooo

http://wwwwwwwwww.

Now they buy it, because...well, because of marketing.

Gerry

 

[dragonwell]

OK, gotta ask - how can I get a copy of Matise?



Greetings,
Dragonwell

 

[fumei]

Of course. I am such an enthusiast that I will copy and send a CD to whomever. No manual though. However, it is so easy to use that even with the so-so Help, it is not a problem.

Two caveats though.

1. This is an OLD program, JPEG was just invented (!!), so the algorithm to produce .jpg files is poor, at best. What I do is make images I am going to work on in Matisse into TIFF, or BMP; work on them in Matisse, save as BMP (or TIFF), and then after convert them into JPEG in something else.

2. Tek-Tips does not like people posting personal email addresses, as they want to prevent spam trolling. So, you could join VBA Express (

http://vbaexpress.com)

and then private message me there; OR play a riddle. It is Gerry with the last name of one who chivalryly rides horses. Put that into Google and, as stated, I am an artist. I am also an astronomer. Email me, send me a snail mail address, and I will fire off a CD.

Gerry

 

[EdwardJS024]

I'll like to throw in my two cents here..I can't tell you what makes software design great, but i can mention what is considered "bad" software design.

At the conceptual level, Robert C. Martin sums it up pretty sufficiently when he talks about the rotting of code. Basically stated, software starts to rot if it exhibits any of the following "odors", as he calls it:

1. Rigidity -
Changing a system is difficult. It forces changes to other parts of the system.

2. Fragility -
When changes are made, the system breaks in unexpected places.

3. Immobility -
Difficulty in reusing components of the system because it is so tightly coupled to the underlying architecture.

4. Needless complexity -
Added infastructure with no real benefit.

5. Needless Repetition -
Similar code is copied-n-pasted throught modules.

6.Opacity -
Difficult to read and understand the code


All of these items really boild down to how well a system can adapt to changes and evolve over time. If software cannot adapt smoothly, it's suffering.

- Edward J.S

 

[stefanwagner]

Which means: most Drag-n-Drop-IDE code is rotten.

I agree.

seeking a job as java-programmer in Berlin:

http://home.arcor.de/hirnstrom/bewerbung

 

[tzigone]

it should capture all alternative beahviours of the user as much as possible and does not handle every alternative possibility as if they are errors.
to be Modifiable, reliable,portable, usable,testable,clear,secure are other issues of course.
but their priorities can change according to user group and environment.