I've been mulling over the implications of the news that Sun's JRuby team leaders, Charles Nutter and Thomas Enebo, are leaving Sun because of uncertainty about the future of their project after the Oracle acquisition. They will be joining Rails specialist Engine Yard. This is the key quote from Nutter:

To be honest, we had no evidence that Oracle wouldn't support JRuby, but we also didn't have any evidence that they would.

JRuby is by all accounts excellent - I'm aware that developers at ThoughtWorks use it, and Ruby advocate Martin Fowler (who works there) told me that it works very well for them, observing that some enterprises who would be reluctant to deploy the native Ruby runtime are more comfortable with running Ruby applications on the JVM (Java Virtual Machine). It is foolish of Oracle to let the JRuby guys slip away, particularly bearing in mind the trend towards dynamic languages (like Ruby) rather than static-typed languages (like Java).

What does this suggest about the future of Java itself under Oracle's stewardship? If Oracle could have done more to reassure Nutter of its continuing commitment to JRuby, so too it could do more to reassure the rest of us that investment in Java and its community will continue as strongly under Oracle as it did under Sun. Maybe it will, maybe it won't; though culturally I suspect the new company will be averse to Sun's habit of investing heavily in projects with little obvious potential for direct revenue. The failure to monetize Java fully, along with the failure of its bold experiment in open source, is one reason for the acquisition itself.

That does not imply that Java will go away - Oracle itself is a heavy user, and defending its future was likely a factor in its willingness to purchase Sun. Still, it would not be surprising if the community is a little less warm, and Oracle's investments more focused on its own needs rather than those of the wider platform.

Despite Oracle, there is no reason to be gloomy about Java's future. There is another way to look at the move of the JRuby team, which is that they've found a way to continue working on the project with or without Oracle's support. Java is bigger than Oracle, just as it was bigger than Sun. 

IBM worked tirelessly to free Java as far as possible from Sun's control, developing its own JVM and creating the Eclipse tools project to foster alternative tools and frameworks. Those efforts will have a new context and relevance.

Maybe Oracle will do great things for the Java platform. Maybe it will do little, and momentum will shift to those outside the home company. Either way, investment in Java development is as safe as anything can be in our uncertain industry.

 

 

Even before I started using agile approaches, I used timeboxes. I actually started to timebox my work when I got my first review as a developer and my boss said, "You don't finish anything. You get 98% of the way done and then you stop." Well, that's because I hate those little details at the end of a task.

Details are not my friend. I can manage them. I can do them. But I hate them. I would much rather eave my hands and say it's done when it's close enough. Well, close enough for the rest of the world appears to much closer than it is for me, so I started using timeboxes when I got that feedback.

I sometimes use timeboxes of no more than 10 minutes when I need to get started on something and I have no idea where to start (such as cleaning my office). I use timeboxes of an hour when I need to see how long something might take and I don't know how to estimate the task. That's enough time to do something useful but not so much time that I get bored and go do something else.

In projects, I frequently use timeboxes of 1-4 weeks, just as the agile lifecycles do. But even if I'm not using an agile lifecycle, there's something quite powerful when I tell the product managers, "You have 2 weeks to define the requirements. We're starting on the architecture after that, so get the good stuff in first." Then, when I tell the architects, "You have 2 weeks to fight about the architecture, and then we're starting on coding." Sometimes, if I think a feature is risky and maybe not so valuable, I'll timebox the coding of it.

One technique I started using back in the '80's was to timebox building and integrating and testing a feature. (This is incremental development, if you weren't sure of what to call it.) I started this when one of my talented developers got lost in the code. He fell in love with a feature, and was adding to it, expanding it, make it fabulous, but he hadn't integrated or tested it. I gave him a week to check the code in, making sure he didn't break the build.

I suspect he called me a variety of names, none of which were particularly nice. On the other hand, he finished the work because he didn't let anything get in the way of this task.

That's the value of the timebox; it focuses you on a particular task. It makes you promise yourself that you will finish this task before the end of the timebox. That focus and urgency help me finish my tasks on time. And, if a task takes longer than the timebox I've allotted, I have learned a lot about that task.

So, if you, like me, have a difficult time with the details, or if you have a tendency to go off on tangents, or if you would like to know how long things actually take, consider using timeboxes. Your project manager will love you :-), and you'll be a lot more productive. 

Microsoft has completed Windows 7 and released it for manufacturing with much fanfare. It is a key step in terms of Microsoft's battle with Apple for hearts, minds, and above all sales; but does it matter to the average corporate developer?

There are a couple of ways of looking at the question. Windows 7 has new features, and although it is unlikely that you would want to require Windows 7 for your application at this early stage, you might want the kudos of adding a few enhancements that appear when running on the new operating system.

The other angle is simply this: if some early adopter insists on running your app on Windows 7, against corporate policy, will it still work?

Windows 7 is an unequivocal improvement on Vista and makes XP look distinctly dated and insecure, so it's likely that adoption will be relatively rapid, especially in the consumer market.

The official line is that application compatibility should be good, and my experience bears that out. In particular, if an application runs OK on Vista it will almost certainly be fine on Windows 7 as well. An XP application is more likely to break on Vista, than a Vista application on Windows 7. User Account Control (UAC) is the biggest source of compatibility issues, particularly for applications that assumed the user to be running with local administrator rights. Test your applications, of course; but unless you are writing tricksy things like anti-virus utilities they will most likely work as well on Windows 7 as they did on Vista.

What about enhancements? Some Windows 7 features are worth supporting, because they improve usability. The most obvious example is the taskbar, the heart of the Windows 7 user interface. Taskbar jump lists, which are right-click menus for taskbar icons, can be customised to support tasks specific to your application; and taskbar preview windows can include controls enabling a miniature user interface for the most common actions. This means users can do some of what they need without opening the main application window at all, which can be a great time-saver.

So how hard is it to add Windows 7 features to your application? An interesting question. Despite the popularity of .NET Languages like C# and Visual Basic for business applications, Windows is mainly written in C++, and when it comes to supporting new features that shows. If you are a C++ developer, you can download the latest SDK and get going immediately.

.NET developers have a more difficult set of choices. You can wait for Windows 7 features to be added to the .NET Framework (it could be a while), or roll your own interop code, or use one of Microsoft's .NET libraries, which are as yet incomplete. The last route is the most tempting, though Microsoft has gone out of its way to confuse matters by producing both sample libraries targetting specific areas, like the Windows 7 Taskbar and Libraries .NET Interop Sample Library, as well as an all-embracing Windows API Code Pack which is I think the preferred solution but which is in some respects even less complete.

Still, it should not be too hard to add some Windows 7 bling to your app using one of the .NET offerings. Then again, hasn't the boss started using a Mac at home? Is it better to invest your time in polishing the experience on Windows, or looking into how you might port to web-based and/or cross-platform applications? Like everything else, it depends; but if you work in .NET it is well worth keeping an eye on Silverlight as well as the latest developments with Windows 7.

Other links:

This official blog post is an overview of the main API changes in Windows 7.

The Windows SDK blog has detailed info and gotchas for bleeding-edge Windows developers.

I have too much to do. It started back when I got the flu and bronchitis back in January. I was sick until mid-March. But even if you're sick, the work doesn't go away. Even working at full speed from March until now (end of June), I'm still behind. Here's my plan for getting out from under:

1. Brain-dump everything I have to do onto one (well, could be several!) pieces of paper. This is from David Allen's Getting Things Done.
2. If I have due dates, make another pass and put due dates next to things, so I can sort by relative importance.
3. Organize the list by importance if necessary.
4. Use Mark Forster's autofocus system to do what I can and what I have energy for, until I either reach a timebox or a wait state.

I know what I have to achieve, if there are dates that I have to meet, and I have my entire todo list in front of me. Now all I have to do is finish things :-)

With businesses keeping an extremely close eye on all spending, departments are being asked to demonstrate tangible benefits from all of their investment. Analysts are required to monitor and report against credit risk, marketing campaigns and customer insight and loyalty among others. With this data they extract, businesses are able to understand their customers and clients in order to match their needs with more targeted investment.

Sectors such as financial, marketing, retail and utilities invest heavily in analytics, but in our experience, almost every sector can benefit from such insight.

For people looking to change careers within the IT sector, or for those entering the workplace after university, an analytics qualification can be a very desirable skill to acquire. The sector has been extremely buoyant and shows little sign of slowing down. Furthermore, the skills are extremely transferable and can allow for easy transition to working in many other sectors.

Those coming from a numerical background in particular, will find the transition to analytical work very natural. However, for anyone with a basic IT skill set, the addition of an analytical qualification can be a very wise investment which, in the long-term, can lead to a varied and rewarding career working within a broad range of opportunities.