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: Thomas Davie <email@hidden>
- Date: Tue, 22 Mar 2005 23:16:56 +0000
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.
Absolutely agreed – a lot of developers need to learn that there's
more to coding that a text editor, a compiler and a debugger. Other
dev tools (and Apple actually provides quite a stunning array), be
they test suites (which apple doesn't provide, but SenTests is nice),
performance tools, graphics tools or something altogether different,
developers should investigate these tools. They can be surprisingly
useful.
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.
IMNSHO - Bullcrap! You should start with what the customer (be they
the user of your shareware program or a paying corporate customer),
from that design the program properly and then start to code... If
you fit the design to what the customer actually needs then you
shouldn't get spaghetti out.
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.
Rubbish - it is my right as a computer user to expect the computer to
do what I tell it to how I tell it to do it. A computer is after all
a tool. Your design should be flexible enough to accommodate all users.
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.
Agreed - but remember that nit-picks are usually what will make your
application stand above the rest. I use OS X because I have such a
huge heap of nit picks with all the other OSes I've tried.
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.
Actually - you should be striving for this... If not, you should be
striving for the program just gracefully recovering from these crazy
situations without presenting any error at all. To reitterate, use
the Cocoa Unit testing tools and you should squash a lot of obvious
ones... then test the hell out of your application.
Bob
_______________________________________________
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