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: "Crichlow, Eric" <email@hidden>
- Date: Tue, 22 Mar 2005 17:08:27 -0500
Wow,
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...
On Mon, 21 Mar 2005, Lorenzo Thurman wrote:
I've bee working IT for about 12 years, both Macs and PC's, and in that
time, I've taken to programming. Mostly for the Mac, but I've managed
to learn and mostly on my own, what I
think is quite a bit about developing for the Mac. I wrote a couple of
small apps that we use to facilitate usage tracking for the computer
labs at the university where I work, and a couple of small things,
thatI find useful at home. I've gotten quite a few tips from this list
and
others that have helped me improve my understanding of Mac programming
immeasurably. Now I've reached a point where I would like to develop an
application for the Mac and release it release as shareware. My big
problem, as I see it, is that since I've never worked in a software
production environment, I'm not sure what I should do as a developer,
to ensure that I have given due diligence to the development of my
product. Sure I can, code, debug(sort of) and test my program, but
there is much more to creating a finished product, right? For example,
I'm not sure how to read a stack trace, how to profile code, etc. Even
if I could profile code, I have no reference point that tells me my
code is functioning efficiently. I'm not sure I'm wording this as well
as I might, so my ultimate question is:
From start to release (since its never really "finished"), how does one
go about developing a real polished program ready for public
consumption? I've looked at some of the programs Apple includes with
the Xcode installer, (CHUD Tools, MallocDebug, etc) and found some
things on the 'net, but I don't feel confident that I can I actually
produce a quality product. Sure, it works just fine on my Mac, but
that's not good enough for a professionally produced product, at least
in my mind. Again, I'm not sure I asking the right way, but maybe some
discussion will help me express my thoughts better.
Any tips, links are greatly appreciated.
TIA
_______________________________________________
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