Windows Phone 7 may not be available yet, but it is a great talking point. Following the collapsing market share of Window Mobile and the Kin debacle, will Microsoft be able to claw its way back into the SmartPhone market? With mobile apps increasingly important in both the consumer and business world, what would be the consequences of failure?
The strategic importance of the platform makes it interesting even if you think that there is little room for Microsoft's phone in a market dominated at the high end by the two As: Apple and Android.
There is even fierce competition among the also-rans, with Nokia pitching Symbian 3 and Maemo/Meego, and HP presumably about to do something with Palm WebOS. And what about Samsung's bada? There will be blood on the carpet; not all these operating systems will survive - and while that will be a shame from the point of view of diversity, it will be a relief to developers attempting to support the broadest number of devices.
So why even bother with Windows Phone 7? Well, there are a couple of obvious reasons. One is the possibility that Microsoft will deliver an excellent and delightful device. Likely? Past form says no; but the company knows what it is up against so you never know; early reviews of preview devices have been generally favourable.
The second reason is less speculative, which is the way Windows Phone 7 fits in with the rest of Microsoft's platform. If you are used to coding in Visual Studio with C#, then creating apps for Microsoft's new phone will be less challenging than doing so for iPhone or Android. A Windows Phone 7 app is essentially a .NET and Silverlight app, or for games XNA, and from what I have seen so far Microsoft has done a good job with the emulator and developer tools.
The disconnect here is that Microsoft's primary target for Windows Phone 7 is the consumer, whereas those armies of Visual Studio developers are largely building corporate apps. Some of them are also annoyed that Microsoft is not providing compatibility with existing Windows Mobile applications.
There are also significant limitations in Windows Phone 7 in its first release. There's no multi-tasking, which means you have to write code to handle your application being shut down and re-activated while giving the appearance of resuming where the user left off. There's no native code, which runs contrary to the instinct of experienced mobile developers, some of whome tried and failed to wrest acceptable performance from the Compact Framework, the mobile .NET Framework from pre-Silverlight days. There's no copy and paste - which does not seem a big deal to me, but some people seem to care a lot about this. Another annoyance is that all apps must be deployed throught Microsoft's Apple-style Marketplace, though I hope and expect that Microsoft will come up with a way round this for corporate roll-outs.
Future iterations of Windows Phone could remove these limitations, but in this instance Microsoft does not have time to release something not very good and get it right three versions later.
I'm keen to hear from developers who have tried the preview devices or the SDK. Like what you see? Intend to support it? I look forward to comments, because the success or failure of this product is going to be significant.
I've been reading a new survey of mobile developers from VisionMobile. Around 400 developers were surveyed, and the platforms covered were iPhone, Android, Symbian, BlackBerry, Java ME, Windows Phone, Flash, and the mobile Web.
The topic is significant. Companies everywhere are crying out for mobile apps, especially for Apple iPhone but increasingly for Google Android as well. The device+cloud computing model is today's big trend, and support for mobile devices in some form or other is becoming necessary for a wide range of applications and web sites.
The first notable fact is the extent to which iPhone and Android dominate. This chart on page 10 tells the story: there is little relationship between the device installed base and the number of available apps. Windows Phone, for example, has 75 million devices out there but only 13,500 apps; iPhone has 60 million devices and 225,000 apps.
The reason is that Apple has created a viable ecosystem for development, as well as a superb mobile platform. Much as I dislike the locked-down nature of that platform, and its Apple tax, I acknowledge and admire what has been achieved.Android has just 20 million devices but 72,000 apps. I'd guess that the quality of those apps is not as high on average, but it's still clear that iPhone now has competition.
If this paper is to be believed, Android will even pass iPhone. Android is identified as the most popular among developers, with around 60% using it versus 50% on iPhone. Why?
We believe that Android's lead in developer mindshare ahead of Apple's iOS is down to two factors: first the $99 fee developers have to pay in order to deploy their applications, an entry barrier which reduces the innovation from developing countries. Secondly, the very effective use of open source licensing as a marketing technique to attract developers to Google's Android.
Another factor is that Android apparently offers the best developer experience. In an appendix, the survey tests iOS, Android, Symbian and Java ME for coding, debugging, device emulation and support resources. Novices could create a simple app more quickly on Android. The coding effort was less; building 9 simple apps took nearly 3000 lines of code on Symbian, versus just under 1500 lines on iPhone and a little over 1000 lines on Android. Debugging is faster on Android. The survey comes up with the following claim:
Using the above data, we can say that when developing common applications, each hour of work for a given Android developer, irrespective of level of experience, equals 1 hour and 10 minutes for a Symbian developer, 1 hour and 20 minutes for a Java ME developer and approximately 1 hour and 30 minutes for an iPhone developer.
Contentious, no doubt, and a lot will depend on what sort of app is being developed. Still, a good result for Android.
Both iPhone and Android seem safe bets, but what about other platforms? Adobe Flash is an interesting one:
Our research further indicates that Flash developer mindshare seems to be in decline, despite Flash's installed handset base of more than 1.3B devices. Adobe's string of execution failures has meant that the installed base for Flash Lite is extremely fragmented, breaking the write-once-show-anywhere story for media brands who are Adobe's key customers. At the same time, Flash, the much-touted replacement for Flash Lite, was more than 18 months late, while Flash Lite shipments have stagnated, dropping from 43 percent to 15 percent of handsets sold from 1H09 to 2H09. This leaves Adobe with a rapidly shrinking window of opportunity, primarily on Android handsets, while having been banned from Apple's growing empire, and slowly seeing the adoption of HTML5, yet another replacement threat for Flash.
That's overly negative in my view. In favour of Flash is that it runs on the Web and desktop as well as on mobile, and will run across a number of mobile platforms. Even so, the research shows the pressure on Adobe to deliver mobile Flash, which will not be in the hands of the public until Android 1.2 "froyo" is availble on devices; and the Apple problem will not go away.
Symbian is in trouble too; in fact, since Nokia is now moving to MeeGo for smartphones, it now has little interest for developers. Some observers think Nokia should go to Android instead.
Java ME? Windows?
The vast majority of Java ME respondents have lost faith in the write-once-runanywhere vision. Moreover, anecdotal developer testimonials suggest that half of Windows Phone MVP developers (valued for their commitment to the platform) carry an iPhone, and would think twice before re-investing in Windows Phone.
That strikes me as accurate. Predicting the future is hard though. Google Android came from nowhere; it is possible that a couple of years from now different patterns will have emerged.
For now though, it's iPhone and Android all the way.
I'm just back from Adobe's partner conference in Amsterdam, where George Neill, Lead Experience Architect at Adobe Consulting, shows us this great slide depicting a woman processing mortgage applications. She has a PC on her desk which is running her organisation's app for managing mortgage applications. However, around here desk are multiple signs of usability failure. On her left, a paper calendar with names and phone numbers handwritten onto deadline days. On her right, an old-fashioned paper roll calculator. In front of her, a pile of paper forms colour coded with post-it notes. The app, Neill notes, should be handling all these tasks, but one glance at the user's working process is sufficient to expose its poor design.
All good stuff. The next thing we see is a nice application built with an Adobe Flex front-end and an Adobe LiveCycle back-end, with the not-so-subtle implication that these user-experience (UX) focused tools will help us create applications that fix this kind of design failure. There's also talk here at Adobe's partner conference of a new era in software built on customer experience, and how consumer technology from iPhone to Facebook and Twitter is raising expectations when it comes to business applications. There are even a few digs at developers, the people who, it is alleged, hate it when requirements change and who develop software geared towards the IT system which which it integrates, rather than towards users.
There is truth in all of this, but I'm cautious. It is easy to find a poor application and poke fun at it, but the idea of observing users and creating applications that improve their productivity is not a new one, and it is not necessary to use Adobe's stuff in order to do good software design. There are even times when it gets in the way. I recall spending time looking for a campsite on the web, for a holiday, and how it was in general the simple HTML sites rather than the "rich" Flash-driven ones that were easier to navigate. Admittedly the average campsite does not create web applications to Enterprise standard, but the underlying point is that there is a case for simple as well as a case for rich. Never forget "skip the intro".
The key question here: how do we define excellence in user experience? Let me state the obvious for the moment.
Applications that have functional deficiencies will not be rescued by any amount of eye candy or beautiful state transitions; and if the user is surrounded by post-it notes and antique calculators I'd suggest that this is not primarily a UX issue, unless we strip all meaning from the term and use it for every aspect of software design, features and performance.
Second, software can deliver a good UX without necessarily having gorgeous graphics and multimedia. As a business software user, I value applications that let me accomplish tasks quickly and easily. Question: think of a web application that changed the world, partly thanks to superb UX? Answer: Google search. Question: how much PhotoShop and Flash was used in designing the fantastic Google home page?
The case for user-centric software design is irrefutable; but we need rigour when it comes to working out what that means and how to achieve it. I like this comment which I found in an 2004 paper by Larry Constantine:
User-centered design is a good idea in need of improvement. The needed improvement is found in practices that put uses rather than users at the center of design and in changing the prime objective from enhancing user experience to enhancing user performance.
UP rather than UX resonates with me. It also reminds me of Kathy Sierra's mantra: creating passionate users. If the current rush towards UX puts the focus there, I am all in favour. If it means newly empowered designers imposing some sort of visual or multimedia experience on us whether we like it or not, count me out.
The iPad has just launched in the UK, queues are long, stock is short, and it is yet another successful new product from Apple. The iPad has frustrations, like no Adobe Flash support for web browsing, no Java, no printing, and the general sense that you do things the Apple way or not at all. Still, users love it and are willing to pay for it, and in the end that is what matters.
Does this shiny gadget have any relevance to the more humdrum world of business IT? I think it does, especially when taken together with other factors. Here's a remark from Apple CEO Steve Jobs from an informal email conversation with Ryan Tate:
The times they are a changin', and some traditional PC folks feel like their world is slipping away. It is.
Yes, it's a Bob Dylan reference; read the entire thread to see why. Jobs is marketing his company's stuff, of course, but a few days later the stock market put some solid evidence behind his claim. Apple's market capitalisation surpassed that of Microsoft for the first time since 1989. Microsoft remains more profitable; but the figures reflect the market's judgment that Apple has better prospects for growth.
Another sign of change comes from one of Microsoft's most important partners, HP. At the end of April it acquired Palm, and with it the WebOS operating system for mobile devices. Whether HP can make a success of WebOS is uncertain; it will not be easy going up against Apple and Google Android. What is more significant is the implication that HP has finally lost faith in Microsoft's ability to get it right in mobile.
Despite some positive buzz around Windows Phone 7, Microsoft did not help its case when it announced a major reshuffle in its Entertainment and Devices division on May 25th. This follows the bewildering launch of the Kin phone - bewildering because it seems right out on its own in terms of strategy - complete with typical Microsoft flaws according to this thoughtful review:
But the obtuseness of this user experience doesn't stop with the Spot -- it permeates the entire interface as though decisions about how things should work were made almost arbitrarily, without anyone stopping to test them in the real world. The Twitter implementation is a great example of that. You can add your Twitter account to the phone and see updates from people you follow, and you can update your status from the top of the Loop... but that's all you can do. You can't retweet something, you can't send a direct message, you can't go to single person's feed to see all their updates, and you can't even open a link in a Twitter message from the Loop!
Windows Phone 7 will have to be much, much better if Microsoft is to claw back any ground in mobile.
I digress. All that matters is that the world is changing, and looking less Microsoft-shaped with each passing day.
In saying that, I don't mean to diminish the excellent work which I see coming out of some parts of Microsoft - Visual Studio 2010, for example - or to ignore the continuing dominance of the company in many areas of business IT. Many companies still standardise on Windows, and Microsoft Office remains the only productivity suite I come across in work.
All true, but the two great IT trends of today are not centred on Windows and Office. One is mobile, the other is cloud computing; and of course there is synergy between them. Apple's iPad is a further advance for mobile, and will drive increasing mobile data usage and increasing demand both for iPad/iPhone applications and for web applications that work well on those devices.
Microsoft's Open XML standard for Office documents is controversial. Depending on your point of view, it somewhere between a breakthrough in opening up the standard in which the world's most popular office suite saves documents, or a cynical ploy to counter the momentum behind OpenOffice and its rival Open Document XML standard. Amidst all the arguments, it is easy to lose sight of the simple fact that, whatever its merits, Microsoft Office does now save by default in an XML format.
When Office 2007 came out, it was not really sensible to use the new XML formats, such as .docx for Word and .xlsx for Excel, outside the safety of an intranet. If you sent one as an email attachment, there was a good chance the recipient would not be able to read it. Still, now we have Office 2010 and SharePoint 2010, and Open XML has become both more important and less troublesome. It is the only format fully supported by the new Office Web Apps, for example. Further, most of us have had to come to terms with Open XML, at least to the extent that we can open them. Maybe it is time to see if the new formats might actually be useful.
The most obvious advantage of XML is that you can read and write documents using standard XML libraries. There is no need to have Microsoft Office installed, or to try and run it behind the scenes on a web server in order to parse or generate documents. That said, an Open XML document is not a single file akin to an HTML page. Instead, it is a set of related XML files bundled together as a ZIP archive, using another Microsoft standard called the Open Packaging Convention (OPC) If you are curious, you can rename a .docx to .zip, extract the files, and have a look.
If you have in mind to generate Office documents using an XML library, the bad news is that it is not a trivial thing to get right. The good news, at least for .NET developers, is that Microsoft has an Open XML SDK that wraps this complexity. The further bad news though is that the SDK does not free you from having to understand how an Open XML document is put together.
I discovered this for myself after downloading the latest version of the SDK, newly updated for Office 2010. I wanted to investigate how easy it would be to have a web application generate Word documents for download. It turned out to be frustrating. There is what looks like a nice help document with the SDK, including Getting Started articles and a complete reference. Unfortunately, it does not tell the whole story. I was able to generate a simple document in no time, but was soon troubleshooting issues. For example, I found that whitespace at the end of text snippets was getting truncated, so that words ran together, until I figured out that a text element needs the space="preserve" attribute, wrapped by the .NET library as SpaceProcessingModeValues.Preserve. Using styles was also tricky. I followed the supplied article on applying a style to a paragraph, but although I used a standard Word style it was ignored. Styles are no use without a StylesDefinitionPart that contains definitions for the styles you will use.
In the end, the SDK documentation is little more than the famously lengthy Open XML specification, presented as classes and members instead of plain XML. There are few useful code examples.
Open XML is also verbose, and makes you realise how concise HTML is by comparison. You can embolden a word in HTML with a simple <b> element, but in Open XML you have to add a RunProperties element to the Run element that has your text, and then add the Bold element to RunProperties. Microsoft mitigates this verbosity by using very short element names; it is also one of the reasons for using ZIP compression on the final bundle.
It does get better, once you have done your homework on the OPC and Open XML, and created your own wrapper code for the .NET API. There is also a fantastic Productivity Tool included with the SDK, with which you can open and inspect Open XML documents. Its best feature is called Reflect Code, and generates the C# which creates the document you have opened. This means you can get a working example for any document, which can also be used as a starting point for your own document generation. For example, you can set up a document with some dummy text using the styles you need, generate the code, and then amend it to replace the dummy text with your own dynamic content. The only snag is that an innocent-looking and nearly blank Word document includes a large amount of metadata, themes and other stuff, so the generated code is over 2,000 lines long.
Microsoft could do a better job with the SDK documentation, but this is still a powerful tool for parsing and generating documents, and delivers a means of processing Microsoft Office files on the server without Office or SharePoint installed. If you want to know more, the official resource site is here. Finally, a commercial alternative with a more developer-friendly API for both binary and Open XML Office documents is Syncfusion's Essential DocIO; I've not used it but have heard good reports.
I've been testing Microsoft's new Office 2010, along with its equally important companion SharePoint 2010, and trying to decide where it lies between brilliance and disaster. It's certainly an improvement on Office 2007. I was relieved to find that Outlook 2010 performs much better than Outlook 2007 did on its first release. Still, the perenniel question with Office is whether you will actually notice the difference, other than a slightly changed colour scheme, as you get on with typing documents in Word and calculating spreadsheets in Excel. While there is the usual laundry list of new features, there's nothing here as dramatic as the switch from menus to the Ribbon in Office 2007.
The real difference lies elsewhere, in how Office is entering the realm of cloud computing. The likes of Google and Salesforce.com have a straightforward proposition: ditch your desktop applications, store everything on our servers, and run your applications in the browser. Microsoft cannot afford to take that line, since Office is its biggest source of income after Windows itself. It has come up with something more nuanced, offering what it hopes are the most beneficial aspects of the cloud without displacing desktop Office.
Therefore we have Office Web Apps, with in-browser creation and editing of Office documents, but still tied to the desktop applications if you need to go beyond basic features. Office Web Apps can live on Microsoft's servers, such as SkyDrive and the recently announced Facebook tie-in docs.com, or on your own servers as a feature of SharePoint 2010. You can use them from various browsers on Windows, Mac and Linux. Suddenly, opening and editing that .docx or .xlsx - these being the controversial Open XML formats - on Linux is not such a problem. I was pleased and surprised by how much the Web Apps improve SharePoint and change the way I use it.
At the same time, as I dug into the Office Web Apps, I found more and more frustrations. The Office Web Apps use the very same formats as desktop Office, but not all their features are available. For example, you cannot insert a new sheet into Excel via the Web App. In fact, there are so many things you cannot do that listing them would take many pages. That doesn't mean the web apps are useless, they are fine for the basics. Microsoft's solution if you need an unavailable feature: just open them in desktop Office. But what if I'm on Linux? Tough.
This same issue leads to problems which are close to being bugs. Let's say I'm in an Internet cafe using a machine that does not have Office installed, you are in the Office, and we are happily collaborating on an Excel spreadsheet - Office Web Apps even lets us edit it simultaneously. The spreadsheet is nearly done, you feel it needs a little jazzing up, and you open it in Excel to add some Word Art. Oops. Not only is the Word Art invisible to me, but I can no longer edit the spreadsheet. Sorry, says Excel Web App. Incompatible features.
It's something that cannot happen in Google Docs, or Adobe's Acrobat.com, where the web application is the only one that you use. I can see this kind of thing causing endless frustration. Note too that you get no warning when editing a document in a way that introduces web app incompatibility.
Office Web Apps is something we did not have before, and you can see it as glass half full, or glass half empty. Personally I expect to use the web apps, and if they help bring an end to the terrible practice of collaborating by emailing documents to all and sundry, I will be grateful.
Nevertheless, as a cloud offering the Office Web Apps are somewhat broken. It will be fascinating to see how this evolves. My guess is that the Web Apps will improve over time, to the point where installing desktop Office becomes unnecessary for many of us. Microsoft may not like the sound of that, but it is better for the company than the alternative, which is not using Office at all. Never bet against the cloud.
Yesterday Microsoft launched a new version of Visual Studio. It's stuffed with new features, has a new shell, and introduces a major new release of the .NET Framework, so there is plenty to take in if you work on Microsoft's platform. In fact, with so many things clamouring for attention it would be easy to give little attention to the brand new language that comes in the package - Microsoft F#. Admittedly the language is not entirely new; it's been around for anyone to try for some time. Nevertheless, it is new to Visual Studio, and giving it the status of a fully-supported language alongside C# and Visual Basic is bound to have an impact.
So why bother with F#? As it happens, I'm writing this from Intel's software conference in Barcelona, where the topic under discussion is parallel programming. We've heard nothing about F# (even in Microsoft's presentation); yet F# is a functional programming language and inherently well-suited to concurrency. One of the key features is that variables are immutable by default, whereas in imperative languages like C# and VB the opposite is true. Immutability makes multi-threaded code much safer.
Here's what F#'s inventor Don Syme told me when I asked him what F# brings to concurrent and asynchronous programming:
There's three things. The first is a real focus on reducing the amount of mutable state in your programming. This means in essence that your mutable state is to be boiled down to the absolute essentials of what has to be mutable. If you do have some mutable state it's local to the user interface thread or local to an agent. But in general you can often completely eliminate the mutable state through this consistent set of functional programming techniques, often by passing some data around explicitly, rather than propagating the data everywhere implicitly by these sort-of global mutable tables. So a focus on immutability first is a major factor.
The second is this Async programming feature which essentially allows you to add lightweight reactions to the system, so you can have many objects waiting to be activated by a callback of some kind, and you can program these objects without doing what's called inversion of control. You can program a series of sequential execution, a series of web requests for example, go to one web site, go to the next web site, go to the next web site and so on, and you can write what we call asynchronous workflows to express this logic which would otherwise be encoded as a set of callbacks all the way through your code. This is extremely important when you're talking about handling errors in a series of asynchronous calls or perhaps accumulating a set of resources across the calls and making sure we clean up file connections and other things that happen during a computational process.
The last thing we bring is an Agent-based programming model built on top of the asynchronous model. This lets you define many hundreds of thousands of agents in memory, in a single process. And this is critical if you're reacting to many different external events such a web crawler having many different i/o requests outstanding at the same time, or processing many different images in parallel.
It's a compelling story; and there are other nice things about F# as well, like the succinct, easy to follow programming style it encourages.
Let me now put this together with a conversation I had yesterday with Intel's Chief Software Evangelist, James Reinders. I asked him about functional programming and he sighed, telling me that yes, languages like F# make parallel programming much easier, but that there was no sign of developers switching to them. In addition, he said, there is so much existing code out there that no functional language can succeed unless it can extend applications written in other languages.
It then struck me how well Microsoft has ticked that box with F#. It is a .NET language, so integrates easily with C# or Visual Basic, and it is presented as a language with which to create libraries for specific tasks, rather than as something you are likely to use for an entire application. It seems to me that it can deliver real value and is well worth exploring.
There's more on F# here; and look out for more from my interview with Don Syme soon.
I'm at Microsoft's MIX conference in Las Vegas, where the big news has been the unveiling of the Windows Phone 7 development platform, and the platform preview of Internet Explorer 9 with extensive HTML 5 support.
There is more to say about both topics; but one thing I want to highlight is that IE9 will not work on Windows XP, the venerable release that will not die.
It is not only that XP remains in use on existing PCs; there are also new machines on sale with this old version of Windows. I've just purchased a netbook, and when making my selection I noticed that many of them still come with XP, usually the Home edition. Some companies still specify XP when buying new PCs, to avoid the compatibility hassles that come with a move to Vista or Windows 7. There's also doubt over the benefits of upgrading. A friend said to me recently, "I really like XP, it does everything I need. What is the point of moving?"
Here's what IE General Manager Dean Hachamovitch told me:
Building a modern browser requires a modern operating system. There are facilities in Windows Vista and Windows 7 around security, for example the integrity level work that gave us protected mode, there are performance improvements that enable a variety of things in the browser, there is graphics infrastructure to take advantage of the GPU, that doesn’t exist in previous operating systems.
A measure of scepticism about such comments is reasonable. Microsoft wants users to buy its latest stuff; there's no surprise there.
Nevertheless, Hachamovitch is right. Windows 7 is more secure and more powerful. Personally I find it easier to use as well, partly thanks to Microsoft's design work on the user interface, and partly because desktop composition in Windows Aero enables richer preview of minimised applications and other good things.
Microsoft is also making a statement with IE9, to the effect that XP users can no longer expect to be included in major product releases. Office 2010 does support Windows XP; but you can bet that the next one will not.
The long life of XP is a side-effect of one specific thing, which is the failure (relatively speaking) of Windows Vista. I used Vista from its first release and regard it as better than its reputation suggests; but nevertheless, it was greedy for hardware resources, prone to annoying slow-downs, and less polished overall that it should have been.
There is also a real issue with application compatibility, introduced with Windows Vista, mainly thanks to User Account Control. This feature protects access to system locations such as the Windows and Progam Files folders, and parts of the Windows Registry, causing problems for some applications that expect full access.
These factors extended the life of Windows XP, resulting in the situation we have today: an operating system coming up to nine years old still in widespread use.
Very often the continuing use of XP is not something we can control. Rather, it is something we have to live with. Nevertheless, it is becoming a liability. Windows 7 improves on XP in every way that I can think of; and we even have XP Mode and Med-V to assist with migration, by running obstinate apps in virtual instances of XP.
Windows XP is something we have to live with, but no longer something to recommend.
Postscript: arriving at the gate for my flight from Las Vegas, I could not resist snapping what seemed the perfect illustration: Windows XP with a sad little error message.
I'm at the QCon conference in London, one that I particularly value for its vendor-neutrality and strong content. Yesterday we heard from Robert Martin, founder of Object Mentor, on the subject of software craftmanship, or how to avoid bad code. One of Martin's points is that having code that works is not enough. He makes an analogy with a machine. It's not enough that your car works; when you open the bonnet you want to see good engineering, not a tangle of pipes, wires and belts that somehow hangs together.
Software is vulnerable to poor craftsmanship because code is often well hidden from customers and end-users. Still, the programmer knows whether they are putting together something that just about works, or crafting something excellent that will be understandable and maintainable long into the future.
Martin's talk turned out to be a practical one. There was nothing really new; but plenty to think about. Here are a few of his tips:
You may not agree with all of these; but I like the underlying objective, which is to code to a high standard rather than just fixing bugs until it runs.
Agree? You can sign the Manifesto for Software Craftsmanship.
I've written positively about Microsoft's forthcoming Visual Studio 2010, both here and more recently in a review on The Register. I was interested to see a kind-of follow up from Jeff Vroom, making the case for doing without an IDE at all, at least some of the time:
Emacs, Vim, and other editors have basic syntax highlighting and code navigation for an even broader set of formats despite the fact that they lag behind IDEs in features. Though IDEs offer impressive plug-in capabilities, traditional script and config files seem easier to learn and use and ultimately more flexible.
Command line workflows offer a more flexible, less integrated and less guided approach to development. You learn how to use them one tool at a time. Development and adoption of new tools is usually easier as you are not tightly coupling tools into one complex user interface. Admins, analysts, and designers use command line tools, making it easier for them to work with developers when the IDE is not front and center.
I don't see a lot of designers using command-line tools; but even so I agree that there is a case for a programmer's editor with command-line compilation, rather than a huge IDE. The two things I like most about the bare metal approach are speed and transparency. Speed, because a little editor like Notepad++ starts in a blink, handles large files with ease, and does not get in your way. It is odd that performance still matters so much in an era of multi-processor machines with each core running at more then 2 GHz; but it does. Sometimes I am caught out when a monster like Adobe Dreamweaver grabs a file association for something like HTML or PHP. I double-click a document, and wait impatiently while it loads all sorts of stuff that I do not need, when I only want to make a small text edit to the code.
Transparency is an even bigger issue. If you work with simple editors and build from the command line, you are forced to be aware of what files are in your project, what tools you are using for the build, and what arguments you are passing to them. If something goes wrong, you know where to look. By contrast, IDEs hide things from you, supposedly for ease of use. In the worst case, something like a Visual Studio solution can get corrupted and leave you not knowing how to fix it, other than to create a new one and add back the files as best you can.
A similar problem comes with wizards that generate code. It is lovely to have the IDE generate all that boring data-binding code for your forms, until there is some weird bug, the results are not as expected, and you end up tracing the SQL and puzzling over why it is wrong.
Valid points; but I am still going to come down mostly on the side of the IDE. It is simple: there are so many genuinely useful tools in something like Visual Studio that productivity is better. Things I don't want to do without include IntelliSense and code completion, debugging tools with things like mouse-hover variable values and watch windows, visual design tools that generate a ton of code I don't have to write, various refactoring utilities, and build tools that save having to think about make or Ant. Visual Studio takes ages to load, but once it is up and running you can always press Shift-Alt-Enter and pretend it is a text editor.
I am still wary of wizards though; and I value knowing how to do without the IDE, even if most of the time I end up using it. As one of the comments to Vroom's piece notes, if it gets to the point where your programming skills are really IDE skills, you should worry about being so deeply tied to a single platform and way of working.
