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: "M. Uli Kusterer" <email@hidden>
- Date: Wed, 23 Mar 2005 20:11:49 +0100
At 10:34 Uhr -0800 23.03.2005, Scott Stevenson wrote:
2. Create an outline which details different areas of functionality,
separating what should be in 1.0, 1.1, 2.0, and so on. I personally
think this should be focused on *what* to do, not which classes to
use. At lot of the implementation details will only become clear as
you work on it.
This is important. If you want to create a good User Interface, the
best way to start is to find out how people will use your app. Most
bad user interfaces happen because people first think about all the
coding details and then just create a window or two with a text field
for every parameter and a few buttons for their methods.
3. Create a basic UI in Interface Builder so that you have something
to plug code into. You don't have to do all of the UI before you
write code -- it's an iterative process.
However, don't be afraid to throw away parts of the UI and
completely redo them. Same goes for code, though there you should
usually refactor (i.e. re-organize existing code) and not do
from-scratch rewrites. When you fix a bug, you learn from it. When
you just throw away buggy code, you may make the same (or a similar)
mistake again the second time. Average programmers write code. Good
programmers can debug code. You'll spend a lot of time debugging, so
get used to it.
5. Find a few people you trust (and have a need for the application)
to be beta testers. Treat their feedback as gold. You don't
necessarily have to implement things exactly as they say, but try to
address any issues to their satisfaction. Ideally, try to get
testers with different types of hardware (low-end desktop, iBook, G5
tower, etc).
Note: You need several levels of testers: Ones that give you
feedback during initial development, and later more when you think
the project is finished and you need to whack out bugs. It's
especially important to get some brand new testers during the final
phase who haven't seen any of your initial attempts. Testers learn to
work around the bugs in your app and get used to your "style" after a
while, and only new people will react as your customers will.
Also, users often ask for specific changes. Don't just implement
those. Find out what problem they're trying to solve, in detail, and
why they need that change. Users will usually only propose minimal
changes (or ones that seem minimal to them), while often each of
these minimal changes just tries to work around a larger problem. If
you find out that 10 small changes are really due to the same larger
bug or inconsistency, fixing that correctly will make your app better
instead of just "fixing" it.
6. Taking feedback from beta testers into account, go back and
smooth out the rough edges.
And remember: It's okay to send out 20 or more beta releases before
deciding on a final release candidate. Warn your testers beforehand.
Most people want to strip debug symbols before shipping so that
people don't know how their code works.
There's another reason to strip debug symbols: It makes your app
smaller by a factor of ten or thereabouts.
7. Presentation matters to Mac OS X users. You do need a good
application icon, toolbar icons, good UI, a website, screenshots,
help, etc. If you can't do these things yourself, hire somebody who
can. This is absolutely essential to selling to Mac users.
A few more presentation-related things: Proofread. Check for
consistent use of colons, terminology, and make sure you don't have
different windows with the same titles...
8. You'll need a way to accept payments and verify registration
numbers. Strangely, this isn't nearly as easy as you'd expect.
eSellerate and Kagi are two of the most popular services to help you
with this.
This is really a surprisingly complicated aspect. I'm currently
doing it manually through PayPal, and it only works because I'm not
selling end-user products, but libraries of interest only to a few
programmers. You'll definitely want a database app to take care of
this, but it's even more fun if you can just have someone else take
care of this. PayPal is good for international sales, though, because
it doesn't require credit cards.
9. Release 1.0. Send announcements to Mac news sites so that people
know about it.
It's important to send to the right address at the news sites and to
make sure you're concise, on topic, and to personalize it a bit. Adam
Engst held a great talk on that topic at ADHOC. Definitely don't just
send CCs to every news site you can think of.
The 1.0 release should be about a set of rock-solid core features.
Instability is a bigger problem than sparse functionality.
Definitely. It's easy to get a bad reputation, and hard to get rid
of it. Also make sure your app is "safe". Most apps somehow
manipulate data provided by the user. The single worst thing you can
do is lock in or even destroy the user's data. And the user's
perception counts here.
Make sure the obvious/important stuff is ridiculously easy. Don't
write code for a feature unless you're confident it will be used.
And read "will be used" as "a lot". Make sure the stuff that people
constantly use works well. Learn about progressive disclosure in UIs.
Make sure that stuff they use rarely is intuitive. If they have to
dig out the manual the same time each year, they'll get annoyed.
This applies to the web site as well. Make sure the visitor can
easily understand what your application does and how it helps them
in less than 30 seconds. Make sure this happens on the *first page*
of the site.
Amen to that. Too many sites assume you know what they're about. If
I did, do you think I would visit? Make sure you think "outside in".
How will someone see this who knows nothing about this (this also
applies to your app itself). Most programmers know so much they think
"inside out".
Oh, and you also need testers for your site.
Always -- always -- include screenshots.
Makes for a good first impression, and helps people evaluate your
app. But it's the last thing I'd add to my site after the above
points.
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
_______________________________________________
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