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:

• Keep functions and methods short. How short? His principle is to use extract method refactoring until there is nothing more to extract. I got the feeling that he would consider anything over 20 lines suspect.
• Have functions with only a few arguments - preferably no more than two - and don't use boolean arguments because they cause confusion.
• Similarly, a class should be a small batch of code, with only a few variables, a couple of dozen methods.
• Eliminate duplication in your code; use abstraction.
• Give public methods short names, but use long descriptive names for private methods. The code is the documentation.
• Improve code slightly every time you touch it. Sometimes the opposite happens; code decays as fixes get added. If you improve it instead, your project improves over time.
• You need comprehensive tests, otherwise you do not dare to make changes in case something breaks. Test code should be of the same quality as production code; if your tests are slow and buggy, you will not use them or trust them.
• Have short iterations. A month may be too long. Two weeks is good. One week, he suggests, may be ideal; or even less in some cases.

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.

• Select a lifecycle that manages the project's primary risks
• Help the sponsors define what success means
• Help everyone define release criteria
  
• To be aware of and manage all kinds of risks. If those risks are technical and the pm has the capability to manage those risks, then the PM can make those decisions. But it's more likely the PM has to make sure someone on the team can make those technical decisions.
• Protect the team's process from outside influence. If the team wants to improve or change their process, great. If someone from the outside wants to impose something on the team, the PM has to protect the team.
• Allow the team to do the technical work and the pm does the rest-of-the-organization interfacing work
• Help the team see when they are making progress and when they are stuck.
  

1. I like helping people define their inch-pebbles. In the case of an agile team, making sure the stories are sufficiently small. I often discover the team members don't know how to make their work units small enough to see progress.
2. Notice when the team's process is not helping them make progress. For example, a long build time or lack of continuous integration can impede a team's progress. If you're the one enmeshed in the situation ("I have to wait for the build to finish" or "I have to wait for John to check in his changes") you may not realize you are not making progress. In that case, the pm needs to put a structure in place to make those problems obvious. On a non-agile project, I do this with one-on-ones. In an agile project, I do this standup meetings.
3. Make sure everyone knows what is most important to work on now and next. I like ranked backlogs, no matter what kind of lifecycle you use on a project.

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.

I'd argue that Microsoft's platform is in decline, despite good financial results recently on the back of the success of Windows 7. Windows-only development is increasingly unattractive in a world where Macs, iPhones and Linux devices such as Android and some netbooks jostle for attention alongside the once all-conquering Windows PC. Microsoft does internet too, of course, and even cross-platform for the desktop if you count what is coming in Silverlight 4.0; but even after the launch of Windows Azure this month, the company is not the first to come to mind when you think cloud.

That said, Visual Studio 2010 is a mighty impressive release. It is not just a new IDE, but also includes .NET Framework 4.0, the first complete update since version 2.0 in 2005. Versions 3.0 and 3.5 used the same underlying runtime as 2.0. The Chief Architect is Rico Mariani, Microsoft's .NET performance expert, which has no doubt helped in the tricky transition to Windows Presentation Foundation for the Visual Studio editor and shell; and much of the product is under the oversight of VP Scott Guthrie, one person who still knows how to communicate with developers, and whose presentation on Silverlight 4.0 rescued last year's Professional Developer's Conference from tedium.

Leaving aside the people involved, there is a ton of interesting stuff to explore, including the new F# language, IntelliTrace debugging that lets you step backwards through code, standard UML diagramming, source code management and issue tracking through Team Foundation no matter how small your team, greatly improved libraries and tools for concurrent programming, and if you have the Ultimate edition and the patience to set it up, an extraordinary thing called Lab Management which integrates virtual machines into the automated build and test cycle so that you can verify clean installs into complex multi-machine environments on every build, and use snapshots to analyse bugs at the moment they occur. This is also the first release to be designed with ASP.NET MVC in mind, and to have a full visual designer for Silverlight. Microsoft has also done some good work with Windows Workflow Foundation, in conjunction with a new runtime for the IIS web server called Windows AppFabric, making it easier to build and deploy applications that depend on long-running state management.

There are some disappointments. One is that Visual Studio is out of synch with Silverlight 4.0, so despite developer attention having largely shifted to the 4.0 release, Visual Studio 2010 will ship with Silverlight 3.0 support. There will be an add-on in due course that will put that right. Another is that Windows Azure development is not as smoothly integrated as I had hoped. SharePoint development, while much improved, remains an arduous process that tends to take over your development machine; and there is not much new in mobile development as yet. I am sure there will be plenty of other problems and frustrations; so much here is new that it is nearly inevitable.

These issue have not stopped me from enjoying my work so far with the beta and now the RC. If you have any interest in Microsoft's platform, I suggest you take a look.

Another not entirely unrelated area is the significance of the mobile web. Mobile phones have had web browsers for as long as anyone can remember; but for most of that time actually using them has been frustrating and slow. Remember trying to scroll a tiny window around some web page broken by non-functioning Javascript or CSS, looking for a critical piece of information such as an address or schedule?

In consequence, the extent of mobile browsing was small and mainly focused on niche areas like travel.

It all changed with the iPhone. Those contracts are expensive, but once you buy in you generally get an unlimited data connection, and more important, a decent browser which is a version of Safari, built with WebKit. That same engine is now used in many other devices, not least those running Google Android. Suddenly, users do want to use their mobiles to browse the web; and they will be hitting your web site or application and trying to use it.

Check your stats. I run another blog at itwriting.com, and when a reader complained about its appearance on a mobile, I added a wordpress plugin which both fixes the layout and reports the traffic. According to the plugin, 5% of the traffic was from mobile users. Once the site was fixed, the figure grew dramatically, to over 15%.

A tech news blog is just the sort of thing that appeals to mobile users, so those figures will not apply in every case. The point though is this: all those assumptions about limited mobile usage which once seemed safe now no longer apply.

Here's another line I often hear. There's no need to optimise your site for mobile, since the more advanced mobile browsers work fine with normal web sites.

Unfortunately that is not the case. They work much better than older ones, true. However, the displays are very much smaller and the connection speed often much slower than on the desktop. If you want your site to be a pleasant experience for mobile users, you will likely have to deliver customised content for them.

Does everyone get this anyway? If you have a few spare minutes, head over to mobiReady and try out a few sites; or download the Android emulator; or of course use a real device to test sites that you are involved in or interested in. I did so before writing this piece, discovering that the web still looks very broken once you go beyond the top sites.

The positive spin on this is that optimising for mobile can be a relatively easy way to gain commercial advantage.

Talking of safe assumptions, one that seems good right now is that the number of web-connected mobile devices is going to grow rapidly in the coming years. Optimising for mobile was always the right thing to do. Now it is essential.

Windows Presentation Foundation was introduced at the same time as Windows Vista, with final code released in November 2006 as part of .NET Framework 3.0. It was designed to replace existing Windows graphics APIs such as GDI and GDI+ with a more powerful, flexible and scaleable framework for buiding a graphical user interface, taking advantage of DirectX hardware acceleration and rich graphical effects. If Vista had proceeeded as originally planned, it would probably have been deeply baked into Windows itself, but in the end took a lesser role, presumably for performance reasons. Microsoft also added Windows XP support to make WPF more attractive to developers.

Another goal was to improve designer/developer workflow. WPF uses XAML, a declarative XML language, and is amenable to manipulation through a visual design tool. Microsoft released Expression Blend and Expression Design, which export XAML, as well as supporting WPF in Visual Studio.

Developing a Windows GUI can be frustrating. If you have ever wrestled with dialog units or the impact of "small" vs "large" fonts, you will know how badly scaling is handled. WPF is a huge improvement, with sensible layout management as well as great support for multimedia and effects.

Nevertheless, WPF was slow to take off. Issues included the large memory footprint of a WPF application, deployment of the latest .NET runtime, and lack of pre-built components; in fact, for a long time Microsoft itself advised against using WPF for line of business applications.

There was another factor too. Long-term Microsoft platform users have learned to be cautious about any technology that is not much used within Microsoft itself. WPF was a great example, with little obvious use beyond the Expression tools themselves. In this context, it was fascinating the hear the talk from Principal Software Engineer Paul Harrington at PDC in November, about how Visual Studio 2010 has been rebuilt with WPF. Harrington's team has an advantage over most of us, in that they can press the WPF team to fix bugs and make changes, and that is exactly what happened. Visual Studio needed to use invisible windows for some operations; WPF did not support that, but now now in version 4.0 it does. The text rendering in the new editor was making some developers feel physically ill, apparently, because of its blurry appearance on some systems, so a new text stack was built, enabled by turning off ClearType. The Visual Studio team ran into problems with focus and activation, and new modes have now been added to WPF to fix them.

My guess is that the stress-testing of the Visual Studio team combined with other improvements in WPF, such as new business-oriented components, will make it the sensible choice for a Windows GUI application, other things being equal (which they never are), once Visual Studio 2010 is released.

The big caveat is that developing new applications using a Windows-only API does not look like a smart choice in many scenarios, though it could still make sense within some organisations, or if your application is strongly hooked into Windows anyway. WPF has good support for new Windows 7 features, for example. But Microsoft is also releasing Silverlight 4.0, which has considerable compatibility with WPF but runs on the Mac as well as on Windows, is easier to deploy, and which fits with the web model for data handling. Silverlight 4.0 now has COM support on Windows, when run out of the browser, which means you can add native code if you really need to, and integrate with other applications such as Microsoft Office.

In some curious way then, WPF is maturing to become an excellent development framework at just the wrong moment. Nevertheless, I'd now think twice before hitting the Windows Forms option on a new application.

Benioff is ebullient and outspoken; a contrast to Microsoft's Ray Ozzie who gave the Azure keynote at the PDC and conveyed little excitement. Of course, it's easier to be ebullient when your company is growing at 20% per year; but another factor is that the Saleforce.com vision is easier to articulate. Throw out your servers, says Benioff, and move everything to the cloud, that is, to us.

In reality Salesforce.com has a significant integration story, so you can have your on-premise applications talk to your cloud applications, but it is not something Benioff talks about much. Why should he? His company profits when you migrate stuff to his platform; the integration piece is merely an enabler.

Microsoft by contrast makes its money from on-premise software. Its internet services lose money, according to its own accounts. It also has a vast partner infrastructure that is sustained by installing and maintaining its products.

Still, Microsoft knows that it has to do cloud, because the economic benefits to its customers are unavoidable, and because any IT company without a cloud strategy will be punished by the financial markets. In consequence, there is an array of consumer services under the Live brand, and an emerging platform of enterprise services under the Azure brand.

Azure is Windows server in the cloud. You get SQL Server; you get IIS; you get ASP.NET; and it is all pay-as-you-go. So is Microsoft suggesting that we throw out our servers? Considering the profitability of its server division, that would be madness; and indeed, the PDC presented mixed messages about the company's cloud strategy.

This was brought home to me by a session I attended on Bridging On-Premise and the Cloud, given by Windows Azure Distinguised Engineer Yousef Khalidi. Cloud computing, said Khalidi, is a "style of computing with dynamically scalable and virtualized resources provided as a service through the network ... this definition doesn't even say if it has to be on the internet or not. It's a way to think about how an application is structured to fit in a cloud-like model."

Khalidi went on to describe a "spectrum" of computing platforms, from the traditional server or datacenter to private and then public clouds. The forthcoming AppFabric Server will make it easier to run cloud-like applications (according to the definition above) on your internal network, with the option to move it to Azure later should you so desire. "Our strategy, our basic thesis guys, is that there are benefits across the whole spectrum and we'll continue to support the whole spectrum," he said.

The snag is that co-ordinating cloud and on-premise gets complicated, as a glance at one of his slides illustrates.

Well, computing is a complex business and I can understand the appeal of this model to Microsoft-platform companies that require some specific benefit, like pay-as-you-do scalability. As an overall proposition though, it is less attractive than the kind of thing Benioff talks about; it can feel like adding complexity rather than reducing it.

Another issue with Azure is that while it lifts much of the IT administrator's burden, it does little to speed development. You still have to write the code, test it, debug it, deploy it, maintain it. Saleforce.com on the other hand is not only a multi-tenant platform, it is a multi-tenant application. If you are lucky, a little bit of customisation is all you need.

You might not be lucky. You might end up having to write mountains of non-portable code in Apex, the Force.com language. You might run into limitations of the platform, like its difficulty with long-running data processing operations that can interfere with the responsiveness of the system. Salesforce.com is also an expensive platform, with per-user per-month fees for ever.

Still, at least Benioff has a coherent story. I'm not sure that Microsoft does.

The latest news is that Microsoft has re-organized Azure into a new Server & Cloud Division. So now the internal division that has most to lose if Azure succeeds is running the whole show. Technically that makes sense; but the marketing message is going to be even harder to articulate.

1. Make sure you've taken any task larger than a half-day chunk and broken it down into smaller tasks. That's why you see draft 1's for articles. I can write a draft in less than a half-day. I can't finish all the editing and have a great article at the end of a half-day. So, I don't try to do so.
2. Be clear on what done means for a particular task. If you don't know what done means, you can't get there. You'll either "finish" without getting to a reasonable stopping point and then you worry, or you can't finish in less than a half-day chunk.
3. Do just that one task until it's done. Commit to it. Finish it.
   

It is a big release too. Many of the top Silverlight feature requests are being implemented, including printing, right-click and mouse wheel support, a rich text control with editing, clipboard support (though text-only in the beta), drag-and-drop, interaction with Webcams and microphones, multitouch control, improved just-in-time compilation for faster performance, and improved databinding for business applications.

In addition, the forthcoming Visual Studio 2010 is the first to have the kind of Silverlight development tools you would expect, with a true visual design surface and drag-and-drop data binding. On the server, WCF (Windows Communication Foundation) RIA Services simplify the effort of authentication, talking to data, and integrating with ASP.NET.

Another notable feature is the ability to run a Silverlight application out of the browser, started from a desktop shortcut and displayed in a custom window. New in version 4.0 is an HTML control, which embeds IE on Windows and WebKit (used in Safari) on the Mac. These are desktop/web application hybrids. Silverlight 4 blurs the boundaries, by adding a new trusted mode. Subject to the user passing a security dialog, a trusted out-of-browser application gets local file access to user data, cross-domain network access, and on Windows native code interop through COM automation.

The snag with this last point is that any Silverlight application which uses COM automation will only run on Windows, breaking the cross-platform compatibility which is a key reason to use Silverlight in the first place. Although Microsoft says the feature has been put in simply to meet the requirements of a few Enterprise customers, it seems to me that it goes well beyond that, making Silverlight viable in many scenarios that previously would have required a native solution.

Microsoft's ideal scenario is one where applications run everywhere, but run best on Windows, preserving its desktop lock-in. The company calls this "lighting up the platform"; but Windows is somehow the only platform that gets lit up.

I still think it is time to learn Silverlight. The reason is not only Microsoft's signposting of this as its key technology for future client development, but something else I saw last week: Google's Chrome OS. I'll be writing more about this; but I was impressed by how this forthcoming browser-based operating system promises to solve long-standing problems: cheap, lightweight computers that are secure, that start up instantly, that give us access to all our data, but can be left in the back of a taxi without compromising our secrets.

What if Chrome OS catches on? Does Microsoft become irrelevant? The real world does not move that fast; but considering the continuing popularity of the Mac along with the prospect of Chrome OS, it strikes me as brave to presume a Windows-only client for future development. Silverlight on the other hand should run in Chrome OS, either using Mono's Moonlight, or the Intel port being done for Moblin, or perhaps Microsoft itself will have to dirty its hands with Linux. Google might block Silverlight - it was non-committal on the subject at the Chrome OS press briefing - but I'm guessing that concerns over appearing excessively controlling will trump the desire to shut out a competitor.

The point here is not that Silverlight is the answer for all client development; there are plenty of other strong choices. The point rather is that for Microsoft platform developers Silverlight is the technology that makes it possible to take your C# or VB.Net skills and transition them to a new cross-platform, web-oriented world.