• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Apple's Tools Strategy
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Apple's Tools Strategy


  • Subject: Re: Apple's Tools Strategy
  • From: Laurence Harris <email@hidden>
  • Date: Sat, 28 Oct 2006 20:27:23 -0400


On Oct 28, 2006, at 5:30 PM, Turtle Creek Software wrote:

This reminds me of tech calls we get from our own users, who sometimes
complain that something is "hard to use". Sometimes when we press them
for specifics they can tell us. But sometimes they get angry and say
something like "Hey, we just run a construction company. YOU write
software. YOU figure it out!"


And they are right.  Users are not software designers.

In this business, sometimes one needs to listen to terribly vague
complaints, and then figure out how to fix them.

Call me unrealistic or even a snob, but the nature of the work we do is such that anyone doing it should have above average analytical skills and be able to express his thoughts. Anyone using Xcode should be able to offer more than "It needs to be better," especially if he's used something he thinks *is* better, as you apparently have.


  Or even harder, guess
about possible problems in advance.  Sometimes it's grueling but it's
part of the job description.

OK, in this case the complainers are users AND software designers. But
we also need to spend a lot of time trying to satisfy our own users,
and improve our own software. We can't necessarily always give a nice
roadmap about how to fix/improve XCode.

Everyone in this discussion has a valid point. As users it's not our job to design Xcode. But if we want Xcode to best meet our needs we need to ensure that the people whose job it *is* to design Xcode know what those needs are. If we don't, we'll end up with an IDE that's ideally suited to writing Xcode at Apple on some of the fastest hardware available.


The reason I get so frustrated with Xcode is that it doesn't meet *my* needs, and apparently the ones I have in mind are pretty common. I only have one PowerPC Mac and one Intel Mac, so I can't use distributed compiles. I don't need 64-bit support, as it won't make a huge difference in what I do and not one customer has ever inquired about it. I don't really care about Fix & Continue. And there are other features the Xcode team has worked long and hard to provide that I just don't use. OTOH, I need efficient ways to navigate my code. (Doesn't everyone, whether he uses a G4 or a Quad core Mac Pro, building applications for PowerPC or Intel?) I need a Find window that's easy to use and let's me have multiple results windows open. I need a one-step mechanism to jump to function implementations. This is the kind of stuff I do all the time. Dozens of times every day. Searching and jumping to definitions were fast and painless in CW. I dread these in Xcode. I've filed an enhancement request to improve jumping to definitions. I offered very specific suggestions. However, if the wizards at Apple can think of better ways to provide what I need, fine by me. And sometimes you're right, we know that the current approach doesn't work well for us, but we don't have a better idea. We should still document the issues as specifically as we can and let them put their heads together to create a solution.

Larry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >Re: Apple's Tools Strategy (From: Turtle Creek Software <email@hidden>)

  • Prev by Date: Re: OutOfMemoryError in my Java app
  • Next by Date: Re: A little off topic ...
  • Previous by thread: Re: Re: Apple's Tools Strategy
  • Next by thread: Re: Apple's Tools Strategy
  • Index(es):
    • Date
    • Thread