An Open Letter to Xcode

I fell asleep while reading the first paragraph.

Why not just suggest the Xcode 4 DRI to write an apology letter? When it comes to Developer Tools, developers are clients too.

I'm not sure how anyone could think a combine harvester that also bakes bread and milks cows represents good or desirable design. Coupling and Cohesion 101, people! Perhaps that's the real root problem with Xcode: its vast, baroque Swiss army knife architecture where it tries to do everything and be everything at once. That's a great way to make a rod for their own (and everyone else's) back. Hopefully Apple will close the ticket on those grounds alone.

Whining about change though - blech, cry me a river. Personally, I'm all for disruptive change when the end result is a clear improvement over what went before. Sure there's a cost to it, but nothing's for free in life, including progress. Heck, imagine if Apple, in a Kodak moment, had never released iPad and iPhone because they didn't want to cannibalize their Mac sales.

Mind you, I suspect I'm not representative of a significant percentage of developers who are crazy over-attached to the vast scads of difficult and arcane knowledge laboriously acquired over the years. They will invariably scream blue murder at the slightest attempt to render that knowledge obsolete or worthless, as that would devalue their high priesthood status and force them to start learning over again like they were just a common noob. Needless to say, that sort of attitude is utterly poisonous to achieving any substantive progress, though perfect for OCD types who think their endless reactionary make-work exercises represent actual productivity.

The only caveat is that radical change can't occur too often, otherwise folks will never be able to find their feet long enough to do any actual work. (Also, beware of burning crusty old bridges too quickly, while folks still have an unavoidable need to stand on them because their replacements are half-assed/unfinished.) But I don't think anyone could ever accuse the Xcode development cycle of reckless velocity; premature releases and inadequate QA, sure, but the actual rate of change is fairly leisurely.

@has Surely that’s not what he meant about the combine harvester, although that’s a problem one gets into when using metaphors.

For me, the problem with Xcode is not that they change it but that each change is accompanied by a long period of time in which basic functions don’t work and it crashes all the time. When they finally get the bugs under control, they throw it away and start anew.

"Surely that’s not what he meant about the combine harvester"

He was the one that characterized Xcode as the 'souped-up combine harvester'.

"For me, the problem with Xcode is not that they change it but that each change is accompanied by a long period of time in which basic functions don’t work and it crashes all the time."

Yep, like I say their QA sucks. Xcode is a business-critical tool for developers; releasing it in half-baked form is a disgrace. Xcode developers should understand this better than anyone else since they eat their own dogfood every day. I suspect it's partly an upper management problem: even though Xcode's a fundamental building block for everything Apple does, it's not an end-user facing product so isn't seen as glamorous or a revenue generator, so gets insufficient time and resources assigned to them. (IT teams often suffer the same attitude, incidentally; no prizes for guessing who gets blamed when core company infrastructure collapses, of course.)

However, I do think the Xcode team's determination to make it into this one enormous monolithic application also contribute to the problems you describe. Many developers love creating these vast monuments to their own egos, but it's a really bad design practice. It makes the whole project less agile, less flexible, and less able to move individual components forward at their own speed and release them when they're individually ready rather than according to a one-size-fits-all release schedule primarily dictated by the need to increment 'Xcode N.0' at regular intervals for appearance's sake.

Whereas a collection of nicely decoupled components, each of which can be developed, released and replaced individually according to its own appropriate schedule, would let them introduce cool new features as and when they are ready, allowing users to get some actual use out of them rather than acting as ersatz alpha testers half the time. That sort of system's harder to engineer, requiring lots of sitting around thinking about the problem, throwaway prototyping, and generally requiring a lot of time to get to the point where it's ready for mass consumption - so it's a difficult sell when micromanaging management only cares about having its developers banging away looking busy. But for something like Xcode I think it's really the only logical long-term solution if you want both flexibility and reliability, and it's a real pity that Apple gave up on OpenDoc-style architectures after the ATG disbanded, especially when the Smalltalk-based Cocoa is such a perfect foundation for it.

And it turns out that there’s a serious bug in Xcode 4.6 that prevents apps compiled using ARC from running on Snow Leopard. (I also reported it as Radar number 13108298.)