Why I Won’t Likely Ever Become A Heavy Mac User

Recently, I received the first Apple Mac computer that I’ve ever owned, an old Power Mac G5 with dual 2.0GHz processors. Obviously, it wasn’t the first Mac that I’ve used; I’ve used systems using Mac OS 8 and Mac OS 9, along with several Mac OS X machines, and emulated System 6 on my main desktop. However, the price of entry into the Macintosh world has always seemed rather steep, especially as the tasks which I usually want to get done seem smoother on Windows (such as computer gaming) or on Linux (such as pretty much everything else right now). So, receiving this machine was my first proper entry point into a world which I’ve always seen from afar.

I’m not exactly short of computers already; I have three desktops and two laptops, running a mixture of Windows and Linux versions, along with a hacked Wii console running Debian Linux and two mobile smart devices: a Nokia E71 phone running Symbian S60 and an old, battered Palm T|X PDA with a faulty screen and the Palm OS 5 operating system. I didn’t exactly need Yet Another Development Box like any of my x86 systems. So, my mind turned to things I could do with the native Mac OS X operating system on it – the version being Mac OS X 10.4 Tiger.

The first idea I had was to conduct iOS development on it, an idea scuppered by the fact that you need an Intel Mac in order to run the iOS SDK. Then, my mind turned to Mac OS X development, which is apparently possible, to some extent, but it’s difficult. Obviously, I knew that the PowerPC processor had been abandoned by Apple several years previous, so it’s not a surprise to see that my Power Mac G5 is largely unsupported by most new pieces of software, it has made me think somewhat about why I’ve never taken the plunge into the world of Apple by myself.

It’s not at all a revelation to state that Apple has always been first and foremost a hardware company which has set itself apart from other computer companies throughout its existence. They have managed to survive, and at various times during their history – including now – thrive in this guise. As such, software has been a means to an end for them, a way of setting themselves apart from hordes of computers running Microsoft Windows. If Apple can figure out ways of making the software in such a way as to keep you buying more Apple hardware, they’ll do it – and have done it several times recently. The iPhone, which I once ridiculed for its limitations, seems like a sensible business decision for Apple not only from the sense of its runaway success, but from the control that Apple can have over the operating system. Of course, they are far from the only computing company who would aim to do this. You can be sure that Microsoft would do the same thing if they could, but they can’t stop companies still developing for Windows XP.

This leaves the case of my unsupported PowerPC-based Power Mac G5. From the perspective of Apple, of course it doesn’t make sense to keep supporting a hardware architecture that they abandoned seven years ago. Apple probably aren’t going to get many new customers for their flashy new desktop and laptop models out of the people who use old PowerPC Macs. Short of supporting iTunes for those few people who are going to use a PowerPC Mac in conjunction with an iOS device, there isn’t much that Apple are really going to want to do with their obsolete hardware.

Clearly, then, I understand Apple’s case in all of this. However, this leads me onto the reason why I’m unlikely to become a major Apple customer in the future. One might suspect with the number of computers that I possess that I’m rather wealthy. This isn’t the case. I’m a student with the typical student income, and with the exception of my dual-core Athlon 64 X2 desktop – which is itself getting long in the tooth – and my dual-core Atom-based netbook, most of my hardware would be strictly considered obsolete. The reason I still keep my older computers is because I can still find a use for them, and with the amount of money that went into them to begin with, I’m not inclined to throw them out.

The extraordinary lifespan of Windows 98 and XP goes some way into explaining why I have been able to keep various systems for so long – as long as my older desktops could play various subsets of my games, I am usually fairly content with their performance. However, the Windows platform only really works for me as a gaming platform a lot of the time. Linux, on the other hand, really gives my older hardware a continued lease of life.

The eclectic collection of people who maintain various versions of Linux, from big companies looking for the best profit margins, to free-software campaigners, to hobbyists who test the flexibility of the software to its limits, have made the operating system many things to many people. The slowest of my computers is an old Pentium III made before the turn of the millennium, with a 450MHz processor and 192MB of RAM, upgraded from its original 64MB of RAM. This is a computer which could still adequately run Linux complete with an appropriate X Window System environment. This, therefore, could still be a very useful machine, still useful for word processing, spreadsheets, basic programming tasks and a limited subset of internet browsing. What’s more, whatever software that I chose to use would still be the most recent version, without the limitations experienced with either Windows or Mac OS X.

If I merely used the most recent version of Windows, I would have had to content myself with the fact that my Pentium III would have been consigned to the scrap heap years ago. My single-core Athlon 64 can just about manage Windows 7, but not particularly quickly. Anything older than that – including my Pentium III and my old Pentium M laptop – would be dead.

In an alternate universe where Mac OS X ran on Intel and AMD computers from the very start, my Pentium III would be a museum piece by now, the equivalent of the Power Mac G3 systems which are more like collector’s items than practical computers for most people. My Pentium M laptop and Athlon 64 desktop would have survived to the Mac OS X 10.5 days, and only my dual-core Athlon 64 X2 system would be capable of running the latest version. This is a complete upgrade cycle on the order of six years, which I can only just about afford right now, and not when I have to consign my older computers to strict obsolescence during that period.

I imagine that for the Apple cognoscenti, this isn’t much of a sacrifice. For me, a student lacking wealth, it is. I am aware of the existence of communities which make a home for older Apple computers and use them, so at least some people can keep their Mac systems going for long periods of time. Unfortunately, there are certain pieces of software – mostly programming tools – which I prefer to keep on the bleeding edge, and you can’t get that with unsupported machines. I can’t blame Apple for their policies regarding their older computers, but I can choose not to participate in them – and for the time being, that’s probably going to be my policy.

Advertisements

Why can’t software development methodologists speak straight?

Author’s Note: Given that I admittedly don’t have enough experience with software development to adequately compare the practical merits of various software development models, I must note that this criticism relates to the terminology that is used in the field, rather than the actual methods used.

As a programming student, I must confess to sometimes being a bit short-sighted, and thinking of problems in terms of the code rather than the problem it’s meant to solve. As such, learning about software development methodology is a slightly difficult task for me, given that I’m inclined to learn by doing, and unless you’re actually on a software development project, rather than an educational-level programming assignment, it’s rather difficult to get an experience of what software development actually entails. That said, when I recently read an article making suggestions to IT staff for improvements to their curricula vitae, and reading a section on words of a masturbatory nature, I considered this for a moment, and thought, “Why do so many terms in software development methodology fit this description?”

To be fair, some of the older names for various software development methodologies seem reasonably sensible. The “waterfall” and “spiral” models might sound silly, but at least they capture some of the essence of the principles involved. Similarly, the “iterative” model actually sounds very reasonable – it does what it says on the tin, without resorting to buzzword-style name conventions. Unfortunately for those of us who prefer not sounding ridiculous when we’re talking about our prospective jobs, the methodologies with these names have become slightly unfashionable in recent years, and people have been attempting to replace them.

The proposed replacements seem to primarily derive from the agile development community. There’s a silly name if ever I heard one; when I think of the word “agile”, I think of cheetahs and house cats (although that might be because I quite like house cats). I don’t think of software development, where its practitioners spend more time sitting down than standing up. What’s agile about that? Are they practicing the quickest way to get out of their chair when they’re called for a meeting? There are many synonyms and near-synonyms for the word “fast” in the English language that they could have chosen instead of “agile”, many of which would be more appropriate for the situations that one is expected to experience when one is developing software.

Regrettably, the practitioners of agile software development have chosen another of the most inappropriate of these synonyms when discussing the rate at which work is completed. “Velocity” is the sort of term I associate with rockets, aeroplanes and fast cars, again not with software development. All I can think of when I hear the word “velocity” in association with software development is somebody strapping an agile development methodologist to the back of a rocket and manically screaming, “What velocity are you at now?!”

Enough of that, though – the terms “agile” and “velocity” are merely risible when it comes to software development, rather than masturbatory. The real sins come when we consider branches of agile development. There are two which come especially to mind: Scrum and Extreme Programming.

There’s a problem with the terminology even as soon as the name of Scrum is spoken. A scrum, as any followers of rugby will realise, is a way of restarting play after a minor infraction. Therefore, the name of this methodology is a sports metaphor. I think it’s obvious why a sports metaphor is not at all an appropriate name for anything in software development. If “agile” was inappropriate, “Scrum” enters the realms of the ridiculous and absurd.

But wait! It gets worse! One of the main roles in the Scrum methodology is the Scrum Master. Having both (unsuccessfully) played rugby in secondary school, and being a fan of professional rugby, this term sends me into apoplexy. What do they mean exactly? The scrum half? The hooker? The number 8? There is no such role as a scrum master in an actual game of rugby. Even as a back, I could see that the scrum was meant to move as a cohesive unit, and wasn’t driven forward by any particular player. It is my fervent belief that the vast majority of people who consider using the Scrum methodology at all are not rugby enthusiasts, and don’t see anything wrong with their clearly ridiculous terminology. Nobody should be allowed to call their methodology “Scrum” until they’ve demonstrated that they can face off against a pack of mad New Zealanders on a pitch. And all of this is before you get to the daily routine. Oh boy. There’s so much wrong with this that I could go on all day.

Instead of doing that, though, in mind of boring you all to death, I’ll move onto Extreme Programming. Again, the problems start right from the name. Extreme Programming could be the best methodology in the world, extracting untold gains in productivity, and I still wouldn’t use it because of the frankly childish and masturbatory name. Apart from extreme sports, the likes of which can be life-threatening, or extreme conditions of any sort, the only legitimate use of the word “extreme” is in an ironic sense, like “extreme ironing”. Programming, as a general rule, is not life-threatening; indeed, the most likely injuries from most people’s programming efforts are paper cuts and repetitive strain injury. Hardly the stuff that you’ll have a war story about, is it?

The few places where programming can lead to life-or-death circumstances seem to be primarily in the embedded sector, where people are programming controllers for industrial machines, or systems for aeroplanes and rockets, or other projects along this line. I therefore propose that we change the meaning of “Extreme Programming” only to refer to projects where there is actually a risk of death or serious injury, instead of having it as a masturbatory name for a way of developing business software, where the consequences of failure might be to mess up somebody’s day instead of sending them face first into a hill at several hundred miles per hour. I rest my case.