Re: [OT] How to be a real programmer
Re: [OT] How to be a real programmer
- Subject: Re: [OT] How to be a real programmer
- From: Mont Rothstein <email@hidden>
- Date: Wed, 23 Mar 2005 13:34:23 -0800
Read "The 22 Immutable Laws of Marketing". It is a short, great, read.
And if you think you found an exception to one of their laws, look
deeper. You can find many examples of them being ignored, but are hard
pressed to find them not being true.
http://www.amazon.com/exec/obidos/tg/detail/-/0887306667/
qid=1111613432/sr=8-1/ref=pd_csp_1/104-3174651-5942322?
v=glance&s=books&n=507846
This is great marketing knowledge no matter what industry you are in,
or what you are selling.
-Mont
On Mar 23, 2005, at 7:16 AM, Lorenzo Thurman wrote:
Actually, I received quite a few replies, and I want to thank everyone
who replied. It makes me feel very fortunate to find so many
"strangers" willing to take the time
to help someone as clueless as myself. Anyway, most of the replies
have been along the lines of "Dude, just do it". So I certainly will.
But anyway, rest assured that I will take yours and all input to heart
and move forward with my project.
On Mar 22, 2005, at 4:08 PM, Crichlow, Eric wrote:
I'm surprised you haven't gotten much response to this. Perhaps it
just
happens to be a pet peeve issue of mine, and nobody else really cares.
Let me hit a few key issues.
Development tools are wonderful. I use an IDE every day. However,
I cut
my teeth in programming almost 2 decades ago on a non-mainstream,
hobbyist
OS without a bunch of cool development tools. Even in just the last 4
years
I have worked at a shop where vi and emacs were the primary editors,
and
command-line compiling was standard. So, while modern development
tools can
be quite useful, I would take great umbrage with someone who
suggested that
their use is mandatory to produce "good" software. Also, in the 10
years
I've spent programming professionally, I've found that the vast
majority of
professional developers tend to use no more than an IDE, and even
then, they
only use its basic text editing and debugging capabilities. Seems to
me that
90% of the functionality of today's development environments goes
unused by
90% of developers. And while it may not be optimal, I think that's
still
perfectly acceptable.
While it's always preferable that shareware have a professional
look and
feel, I think you have a lot more leeway with shareware to take some
stands
that developers on major commercial products can't take. Over the
last 2 1/2
years working on the commercial product that I currently work on,
I've been
seriously aggravated a number of times at having to IMNSHO, waste
dozens of
hours of programming to make a feature work exactly the way marketing
wants
it to, because they think users will be bothered if it works
otherwise. I've
had to twist and turn code in rather ugly ways (when clean, more
reliable
code would have been, as it always is, much more preferable) because
someone
thought that something should only take one mouse click to accomplish
instead of 2. In some cases, that makes some sense. But for a
function a
user is likely to use only a handful of times in one session, it's
ridiculous.
Frankly, I think Mac and Windows users are WAY too spoiled. But
then,
that's because I come from a time when I was HAPPY just to have a
program
that did xyz, and didn't complain one bit that I had to adjust to the
way
the programmer decided to design their app.
My suggestion: if you're doing shareware, design it in a way that
you
think is reasonable. NOT for the sake of being lazy and taking
shortcuts,
just in a way that makes sense to you. If the program is useful
enough,
users will adjust to little idiosyncrasies that they may not agree
with.
Some will make suggestions. Take them to heart, but make judgements
as to
whether or not the suggestions are legitimate, or nit-picky.
As for testing. There's only so much you can do. Personally,
first off,
I keep a bootable partition with the last major release of the OS on
it, so
I can at least test with the current OS release (10.3 in this case)
and the
last major release (10.2 in this case). If you're a registered
developer, it
doesn't hurt to have a boot for the latest development build of the
next
major release to test on. Testing isn't much fun, but at least you
should go
through every function of your program, testing for success. Then it
makes
sense to test each function for probable error conditions. And
finally, just
throw some random, crazy situations at it, and try to make sure you
handle
them reasonably well. The program should never crash, but I don't
think you
have to have a custom error dialog expaining every little problem for
every
crazy situation a user might get into just trying to break your
program.
Of course, being "old-school", to me, "shareware" means a program
that
is offered, FULLY functional, for free, with the request that users
donate
money if they find it useful. Today's definition seems to have
crossed a
line into what I consider "commercial" software. If you're charging
for full
functionality, then some of the things I said no longer apply, and you
should apply the same restrictions to yourself that apply to larger
commercial applications.
...Eric...
Tech/Library Combo Lab Manager
Northwestern University
Office Tech MG49
mailto:email@hidden
voice: 847-467-6565
pager: 847-536-0094
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden