Pinderkent

Through my work, I get to visit and work with many different businesses and organizations each year. And like anyone involved in business, meetings happen (far too) frequently, and they often include presentations. Although I don't have to give them very often, I do get to sit through them frequently enough. As laptop computers and projectors have become more prevalent, we've seen slideshows and similar presentations become used more often. While major mistakes can be made easily enough when using whiteboards, handouts and other presentation media, the laptop/projector/PowerPoint combination makes mistakes almost certain for some people.

By "mistakes" I don't mean minor stumbles while speaking, momentarily forgetting what to say, and so forth. I'm talking about incidents that can, within a few seconds, ruin the reputation of the presenter and the party or parties they may represent, or perhaps put an end to a valuable deal that has been in the works for some time. Although somewhat rare, they do happen more frequently than they probably should.

Those who have sat through enough presentations will no doubt have seen scenarios where a rogue popup alert window, often from a networked application like and email client or an instant messenging client, inadvertently displays some unsavory or very personal information. Similarly, some malware may open popups with various advertisements that do no reflect well on the presenter. Another major problem is personal and/or inappropriate photographs accidentally being displayed as thumbnails in the file browser while the presenter is starting to open their presentation. And sometimes laptop users have set a sound file to automatically play when their laptop turns on, but forget to turn down the speaker volume before turning their laptop on before the presentation.

Matt Hulett recently gave some tips to help avoid such mistakes. With respect to his first two tips, one good method of achieving that is, as mentioned by one of the commenters, to have a separate account on the laptop solely for presentations. I know some frequent presenters who take that a step further, and have separate accounts for each presentation, to avoid having the presentation for one group inadvertently displayed to another.

Some of those presenters even have a separate laptop they use just for presentations, and another laptop computer they use for work and personal purposes. I know one fellow in particular who uses a very minimalistic installation of Debian on his laptop. He doesn't even bother with installing a desktop environment, instead just using twm. Essentially, he has stripped his presentation laptop down to the bare minimum needed to make his presentations, and by doing so has eliminated many of the possible causes of major incidents. One thing he even told me is that he uses a shell session running in xterm to navigate his filesystem and start his presentations, to help avoid unintentionally revealing unwanted information to his audience.

With some care, preparation and forethought, it's often relatively easy to make a presentation go well. But it's also quite easy to be in a rush and forget something minor, such as closing down a running email client. Soon enough this can balloon out into an angry audience, and possibly even the end of valuable business relationships. A secondary, minimalistic, presentation-only laptop with separate user accounts for each presentation will go a long way towards preventing some of the most common incidents. Adequate preparation usually takes care of the rest. And if all goes well, the presentation will be a success.

I read an article today suggesting that functional programming hasn't caught on widely because most developers today haven't been convinced that it is necessary. I'm not sure that's completely correct. Those who are truly "in the know" will have been at least investigating functional programming for some time now. The rest can merely be considered stragglers, who don't yet realize that they currently do have, or will have, a need for functional programming in the near future.

Although it was clear several years ago, we can now say with almost complete certainty now that we will soon be seeing consumer-grade PCs with 32 or more logical processors. Intel's Core i7 has recently brought us part of the way there. At the higher end, Sun's UltraSPARC T2, for instance, offers 8 cores for 64 threads of execution. The trend is obviously towards processors offering multiple cores, each of which may offer multiple threads of execution. And today's mainstream programming languages just don't take advantage of such environments too well.

Some industries have dealt with these issues already. That's why Erlang has been around for over 20 years now. Anyone who has worked on telecom systems or even just worked with Erlang knows the benefits that its concurrency model brings. These days, with the advent of consumer-grade multicore CPUs, such benefits are applicable even when using the low-end systems. In fact, to make the most of today's and tomorrow's CPUs, we will need to develop our software to be more concurrent.

To do this effectively, we likely will need to make use of at least some of the techniques pioneered by the functional programming community. Immutability is perhaps the most important and useful technique when writing concurrent software. Strong, static typing as offered by languages like Haskell and Standard ML is also very useful. Well-integrated support for writing concurrent applications, such as that offered by Erlang, is another major benefit.

However, we likely won't see the development community at large using Haskell, ML or Erlang any time soon. What we'll probably see first is a move towards hybrid or multi-paradigm languages. Clojure and Scala are two of the most familiar at this point. Both target the Java platform, which makes them appealing to existing Java users.

Somewhat surprisingly, Microsoft may very well be the ones who bring functional programming to the mainstream, through their F# language that is to be included as part of Visual Studio 2010. Functional programming will quickly be made easily accessible to a large number of application developers, at a critical time when many will likely be looking for ways to better leverage systems with many logical processors.

Unfortunately, Sun seems content with spinning their wheels with Java and worse, JavaFX Script. Given Sun's long history providing back-end hardware and software, especially hardware that offers many threads of execution, it's sort of surprising that they aren't giving more support to languages like Clojure and Scala. These are the sort of languages that give current JVM users the boost they need to remain or even become competitive.

We're starting to see a variety of factors come together now that will make functional programming techniques far more useful to the mainstream software developer. Multicore CPUs are now readily available, including in low-end consumer-grade desktops and laptops. This will start increasing the demand for efficient, scalable and practical methods of making use of these resources. A variety of open source functional languages, like Haskell, Erlang, Scala and Clojure, have shown that they're willing to help meet these demands. Microsoft is going with F#. The need to use functional techniques combined with readily-available language implementations will allow for this flourishing to occur.

It's a mistake to think that unit testing is only about preventing bugs. As such, it's also a mistake to measure the usefulness of writing unit tests in terms of the number of bugs found. Unit tests are a preventative measure, both when initially writing a piece of code for the first time, and for ensuring that future changes have not broken it in some way.

Of course, I'm not the first to point this out. But it's unfortunately a concept that is missed by many in the software development field. Many such developers have difficulty thinking about the "intangible" aspects of automated unit tests. All they're immediately aware of is the time and effort it took to implement the unit tests. But they don't realize how the act of developing the unit tests made them consider to a greater extent how their unit of code would eventually be used. In proper test-driven development, the developers would get a better sense of how their unit's API should be structured. If they're good developers, they would also have put more consideration into how corner cases would be handled. And once their unit tests are implemented, the ability to run them continuously against a changing code base becomes invaluable, especially when regressions are caught rapidly.

Such developers can easily track the number of hours it took them to write the unit tests. They can easily track the number of lines of code making up those tests. But it's harder to quantify the greater familiarity and greater understanding they gain regarding the unit under test. It's also difficult to quantify the time and expense saved by catching regressions as early as possible, often within seconds of some new or modified code being committed to the source code repository. And then there's the software developer's reputation, be that developer an individual or a large company, which can be greatly improved by providing software that is generally bug free.

Often, the benefit brought by the more intangible and abstract aspects of unit testing far outweigh whatever time and effort is put into developing the unit tests initially. Remember, if a unit test that took a few minutes to write catches even one regression, the savings can be enormous. Many times in the past I've seen days upon days of effort, in terms of debugging, patch preparation, patch testing, patch deployment and customer appeasement, needed to fix a bug that could have easily been caught with three or four assertions and perhaps eight to ten lines of unit test code.

Today I was forwarded a link to an article about how Internet Explorer 6's market share appears to finally be declining. Most people, and especially Web developers, would agree that this is a very good development. It is not known as a secure product by any means, and is woefully inadequate compared to other browsers today. Unfortunately, it still has a significant presence within the business community, even almost eight years after its initial release.

The problem in this case isn't really with larger businesses and organizations. Many of them with dedicated IT departments have moved over to Mozilla Firefox, with others moving towards IE7. In many cases, the move away from IE6 was done to improve security, while in other cases it was done because users demanded the better functionality offered by Firefox, like tabbed browsing and ad-blocking support.

But we don't really see this with many smaller businesses and organizations. I'm talking about medical offices, small shops, car dealerships, private schools, and so forth. Most of these places do not have a dedicated IT person, let alone a team. They'll get a small computer network installed, and they'll use it for over a decade. Many don't have a choice; they can't afford a better or more up-to-date IT infrastructure. For many others, computers are an "evil" necessity, which the business owner manages to tolerate.

I work with businesses like this relatively frequently. And many of them still are using IE6, unfortunately, with no plans to upgrade. In some cases, it's relatively easy to talk the owner or manager into switching to Firefox. Even if they don't understand the technical and security-related problems with IE6, they've heard about Firefox, Opera and/or Safari from their children, friends and relatives, and are willing to give them a try.

There are others, however, who refuse to switch. In some cases it took these individuals years to get accustomed to IE6, and they're just not willing to put forth the time and effort to learn how to use another Web browser. Those of us who work in IT and software development might find this laughable, but it's a very real attitude. I've actually worked with one business in the past year where they were still using Windows 95, with IE3 as their Web browser. Even though their browsing experience was terrible, the owner refused to upgrade from Windows 95. To some extent, this actually benefited them. Their staff were unable to use the Web to check their email, use Facebook, or visit other sites that might distract them from their work.

Those who I feel worst for are the businesses who want to switch, but they're unable to due to some part of their application suite only really being supported well by IE6. One company I worked with recently had an intranet app that used a proprietary ActiveX control. They had lost contact with the developers who had originally put together their software, and unfortunately did not have source access to this critical and specialized control. They'd tried upgrading one of their systems to IE7 on their own, but their app wouldn't work with IE7 for some reason. So for the time being they have decided to remain with IE6.

Although IE6's market share is declining, it will still be with us for some time. Hopefully we get to the point fairly soon where its use is marginal, and the vast majority of Web sites can ignore Internet Explorer 6 compatibility for the most part. This will make life easier for many people from the Web developers who have to put in extra effort to make a site work well with IE6, to the system administrators who have to worry about the security flaws it presents, to the users who have come to realize the benefit of ad blocking and tabbed browsing.

Today I perused an article suggesting that Microsoft is a "dying giant". While that article is correct to point out that we are seeing things change for Microsoft, I don't think the article's interpretation was correct. They're adapting to changing circumstances, and are doing a better job than many of their competitors.

Yes, they have or will be making some significant layoffs. That's often necessary during a time of change. Efficiency and productivity has become a necessity, and those who don't offer one or both must go.

But unlike many of their competitors, especially Sun, Microsoft has potential. They're going in the right direction where it matters. One such example is F#. With virtually every PC sold these days having CPUs with two or more cores, software will need to start making better use of such resources. One of the most effective ways of doing this is through the techniques of functional programming. With the release of Visual Studio 2010, which will include support for F#, Microsoft will bring functional programming to the masses.

Sun has failed miserably in this respect. Considering the hardware they offer, they should have been at the forefront of delivering what it takes to write effective software that runs on systems with 32 or more processing units. After all, that is what we'll see in typical desktops in a few years, if not sooner.

Java has stagnated, and in many ways is becoming irrelevant in the coming software development world. While Java did help bring multithreaded programming to a wider audience, its techniques are no longer suitable. We, as developers, need functional programming. So Sun should probably have put much more emphasis on programming languages that target the JVM like Scala and Clojure, rather than Java. They do offer the functional programming capabilities that we're really beginning to need these days, and that we'll find crucial in the very near future.

Although I have used Sun's hardware and software for years, and have very much enjoyed using them, I see Microsoft as bringing more innovation and practicality to developers than Sun is these days. So although Microsoft is falling on some troubling times these days, as most companies and individuals are, they have a better future ahead of them. They're adapting during these crucial times, and will be much better prepared to face the computers we will be using shortly.