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: Scott Stevenson <email@hidden>
- Date: Wed, 23 Mar 2005 10:34:53 -0800
On Mar 21, 2005, at 3:17 PM, Lorenzo Thurman wrote:
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.
There's no mystical process. The basic premise is:
1. Get something basic working. Cocoa makes this really easy.
Prototyping helps you visualize your ideas and decide if it's something
you want to keep working on.
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.
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.
4. Implement the application according to the outline, making changes
to the outline itself as you discover things along the way. Don't get
stuck on any one issue too long. Objective-C makes it easy for you to
"stub out" features with nonexistent classes or methods.
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).
6. Taking feedback from beta testers into account, go back and smooth
out the rough edges. If you're told the application is too slow at
certain places, fire up Shark. This is a *fantastic* tool, though it
takes some getting used to (see
<http://developer.apple.com/tools/shark_optimize.html>). Also use
ObjectAlloc to make sure you don't have memory leaks. Most people want
to strip debug symbols before shipping so that people don't know how
their code works.
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.
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.
9. Release 1.0. Send announcements to Mac news sites so that people
know about it. The 1.0 release should be about a set of rock-solid core
features. Instability is a bigger problem than sparse functionality.
Perhaps the most important thing is to not go bananas on adding
features in the outline. Although you may not know it from technology
mailing lists, the vast majority of the worlds feels that software is
too complicated. Make sure the obvious/important stuff is ridiculously
easy. Don't write code for a feature unless you're confident it will be
used.
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. Always -- always -- include screenshots.
Hope that helps,
- Scott
--
http://treehouseideas.com/
http://theocacao.com/ [blog]
_______________________________________________
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