Developer paths beyond the Visual Studio juggernaut

I have just purchased a Mac laptop and am planning to partition it to run OSX and Ubuntu. Currently I use Microsoft Visual Studio on Windows for development projects. My concern is whether there is an equivalent to Visual Studio and the Microsoft Developer Network (MSDN) on OS X or Ubuntu?

Today I was asked this question, one which is very similar to others I have been asked and answered in the past. In Windows the decisions a developer must make prior to starting coding are relatively simple because it is an environment dominated by Visual Studio. When making the move to OSX or Linux the decisions facing the developer are more complicated because no single company dominates these platforms in the same way Microsoft does Windows.

Outside of this Microsoft’s sphere of influence is a large number of avenues to consider which can significantly influence the productivity and even success, of your software project. The short answer is there no direct equivalent to Visual Studio and MSDN for OSX or Ubuntu, but there are plenty of satisfactory alternatives. In making your decision consider what languages you use now, or are interested in learning in the future. Also identify what general platform you wish to develop for; be it the desktop, server, web or mobile. And always remember whilst none of these discussed paths are wrong, some are more right than others depending on the project.

Doom & gloom programmer keynote by Tim Bray

Tim Bray's Future of Web Apps 2008 keynote has been published to the web. Unfortunately he does not paint a rosy future for developers given the current economic climate. Entitled "The Fear Factor", according to Tim he rewrote the script the night before after spending a couple of depressing days with London bankers and watching television news.

Tim gives a very down to earth presentation that sits in stark contrast to most bright and breezy keynotes you see posted to the Web. The underlying concept is that the credit crunch will force many companies to suspend broad, big budget development in favor of small, low-cost projects. In this environment there will be project cancellations and job losses, so if you are a programmer it is a case of staying competitive through learning and networking more than your competition.

Some of the interesting points raised in the half hour keynote were:

  • Monetisation will occur at the point of value. Rather than $100,000 up-front licenses, companies will be looking to pay only once a system is in production i.e. Open source will hold a significant business advantage.
  • Waterfall is dead. In an uncertain, credit-poor economy the idea that a project can go for 14 months without delivering value will be seen as unacceptable to decision makers.
  • The Cloud is good, but lock-in is bad. Companies will value the cost savings from on-demand services like Amazon Web Services and Google App Engine, but be wary of the pitfalls of vendor lock-in (we do not want another Windows monopoly).
  • With regulation comes business opportunities. Governments around the world will be passing legislation to ensure another financial crisis is avoided. From a software development standpoint this will create a significant opportunities for those in the right place with the right abilities.
  • Mobile technology and micro-transactions are the new fertile ground. Apple iPhone and Google Android have realised the development potential of the mobile device. Their application marketplaces are vibrant economies where micro-transactions of $1-$5 rule.
  • Build something for yourself. You will only be truly successful at building something that satisfies your own needs. Steve Yegge has said it best in "business requirements are bullshit".
  • Do not be a [insert language here] developer. The idea that someone can ever learn and use one computer language (e.g. Java, PHP, Ruby, etc.) in a competitive marketplace will not cut the mustard. Be a 'web developer' who is prepared to explore anything, even legacy code - you never know where it will lead.
  • Network, network, network. Nine times out of ten work will come from people you know rather than what you know. Do not expect the plum jobs to land in your lap if you do not participate in communities. e.g. conferences, mailing lists, blogs, Twitter, etc.

Overall it is a very good, down to earth talk that provides a valuable reality check in these "interesting times".


Architecture Astronauts

A blog post by David Megginson brought to my attention an article posted six years ago by Joel Spolsky about architecture astronauts. Who are they? Architecture astronauts in Joel's words are:

"Smart thinkers (that) just don't know when to stop, and they create these absurd, all-encompassing, high-level pictures of the universe that are all good and fine, but don't actually mean anything at all."

The moral behind Spolsky's story will continue to remain relevant simply because it is a lesson often forgotten in the heat of a debate or brainstorming session. David Megginson agrees with many of these observations but does point out architecture astronauts have had a positive, if not always successful effect on technology development. From the real world of architecture I am always reminded of Mies van der Roe's ability to grasp the big ideas of modernism whilst still keeping his head when it came to functionality and details (after all, 'God is in the details'). This ability gains even more credit when you compare his work to Le Corbusier, arguably one of architecture's great astronauts, who's ideas often far outstretched their functionality or success in the real world.

On a technical tangent I especially agree with one of David's last points about XML and the heady effect it has had on technology architects and evangelists in the past:

"(Architecture astronauts) believe that if a bit of standardization is good, a lot must be even better."

If anything both posts highlight the importance of stopping work, taking a step back and readdressing what it is you are actually trying to achieve and the way it is being done. Unfortunately for most of us it is all too easy to get caught up in the big idea or the nuts and bolts, in the process missing the chance to grasp what we were really on to in the first place.

Software design choices and the Vista shutdown menu

Windows Vista is Microsoft's very delayed 'next-generation' operating system finally shipping to consumers this December/January. Whilst aesthetically similar to Windows XP it offers a host of new functionality. One new piece of functionality that has drawn a lot of criticism has been the overly complicated shutdown menu. You would think shutting down your computer would be simple but Vista now offers nine different ways of ending your Windows session from the 'start' menu. The result is confusing, ugly and a pain to use. Joel on Software has a well considered article on how too much choice, whilst good in theory is bad in practice and uses this new shutdown functionality as an example of the problem.

Simplification and a healthy dose of logic is usually the answer to these problems but this can only come when the decision making process is clean and crisp. Unfortunately in the case of Windows Vista the decision making process was far from this. Moishe Lettvin was part of the shutdown UI team on Windows Vista and in a blog posting he describes the painful process behind this little piece of functionality (comprising of just a couple of hundred lines of code). The feature is the ultimate example of design by distributed committee as it received input from 43 different people. The consequence of this? After one year of development the 'team' produced a traditional, option packed menu. If his post is an indication of the software development beuarcaracy and process issues within Microsoft then they are in serious trouble. Without significant changes Windows Vista will symbolise only the tip of the iceberg when it comes to overdue, feature-incomplete products emerging from Microsoft development labs in the coming years.

To open source or not open source, that is the question

Thanks to Ted Haegar I came across a piece by Tony Whitmore on a similar topic to my Novell Open Audio review. Tony raises a couple of good ideological questions about the development models at work within Novell, more precisely around the AppArmor and XGL products. Whilst each software project is unique in its own way his questioning of the strategies employed by Novell does beg the difficult question, how open source should product development be?

Software Development

During the working day (and night) a large portion of my time is spent developing web-based software solutions for organisations located within Wellington, New Zealand. Most of this development is related to knowledege management, primarily the field human resources.
Development is undertaken in the Java programming language as it is powerful yet flexible enough to be deployed on any major operating system in use.