How much pressure is required to make somebody more productive?

Michael has written another great post here. I don’t want to steal his thunder, so please go read his post (it’s an excellent read), then read my thoughts below!

Earlier this year a good friend and colleague was discussing (with my boss) the idea of increasing workload and the pressure required to improve/increase productivity. Working out just how much more work an individual can cope with is difficult and is one that Michael covers in his post. Too much work and the individual goes in to shutdown mode, too little and they procrastinate.

Whilst I agree with increasing a person’s workload, it’s important to consider the unseen work they might be undertaking. For example, and I don’t wish to blow my own trumpet, I put in a lot of hours for my employer (more on this in a moment) and I put in a lot of voluntary hours writing/presenting for Scottish Developers, the Developers’ Group and Agile Scotland, amongst others.

I’ve recently seen my employer’s workload increase, particularly the amount of travel has increased. This has meant sacrifices elsewhere: writing takes time and inclination, without both, writer’s block is very common. After a working week involving a lot of travel and 6-8 hours of working time each day too, one doesn’t really feel up to firing up the laptop to start work on articles and presentations!

Earlier in this post I mentioned that I put in a lot of hours for my employer. I put the hours in just to get the job done: and I try my best to make sure it’s a “good job, well done” too. I’m sure that I procrastinate, who doesn’t? I’m sure that I sometimes take longer to complete a task than the next person, again who doesn’t? What I have noticed however, and this is a general observation, not specific to any organisation, is that there are folks out there who take a long time completing what should be a simple task. Of course, there are similar folks who can complete the same simple task in a much shorter time-scale than was ever expected.

Productivity comes through “getting on with it”, it comes with the realisation of “task completion”: the more tasks that an individual completes, the more productive they should become. Ultimately, the individual will set their own threshold. For productive individuals, this will be easy and should require no outside involvement, which, IMHO, is a bad thing: outsiders shouldn’t try and alter individuals thresholds unless the individual concerned is the worst kind of procrastinator, the kind who never finishes anything.

The Best of Delphi 2005

the best of Delphi 2005
On the 29th of November 2004 I will be speaking at The Best of Delphi 2005: an event organised by The Developers’ Group.

The event takes place here: 1 Whitehall Place, London, SW1A 2EJ and starts at 0900 – be there!

The full agenda can be found here.

I’ll be speaking about two subjects: refactoring and XML Web Services.

I don’t know about you, but I’m a lazy coder: I like my IDE to help me as much as possible. I used to be happy with simple stuff like indenting or “outdenting” blocks of code. Then along came code completion, heaven! Naturally I crave for more, more productivity gains, more guarantees that the code I write is syntactically correct and it is consistent.

The refactoring support in Delphi 2005 provides such guarantees: no longer do you have to rely on cut’n’paste to move chunks of code around (many a customer-facing error has been made with “cut’n’paste”!).

Use Refactoring To Move From Win32 Delphi to Delphi 2005
Moving your application from one version of Delphi to another is never quite as easy as it looks. Even more so if it’s from Win32 Delphi to Delphi for .NET!

Consider a legacy Delphi 5 application that was written around the time Delphi 5 was released. Like all code that was written “a while ago” (a couple of weeks ago in my case!), you probably look at some old code and think: “did I really write that?” and/or “I haven’t a clue how that piece of code actually works”. If those quotations ring true for you, Delphi 2005’s refactoring (and unit testing) is something you should be very interested in: refactor what you don’t understand.

Delphi 2005’s refactorings will let you re-write (alter the design of) your old code whilst preserving the functionality. Similarly, if you don’t understand how a piece of code works, Delphi 2005’s unit testing will let you write tests to “surface” an understanding.

If your application doesn’t use any third party components, then moving from say Delphi 5 to 6 or 5 to 7 is probably the simple matter of a recompile, perhaps with one or two minor code changes.

However, if your application uses third party components, your move to a new version of Delphi typically will involve an upgrading those very same components! And this is where it can get a little hairy. My experience has shown that moving a moderate-sized application from Delphi 5 to Delphi 7, whilst taking into account a raft of third party component upgrades, sparks off the need to re-test and often re-write large parts of the application.

Similarly, moving from Win32 Delphi to Delphi 8 or Delphi 2005 also necessitates that your application is retested after the move.

It is for reasons like these that Borland have incorporated two features into Delphi 2005: refactoring support and unit testing via NUnit. Refactoring brings with it the productivity gains we are all looking for and NUnit provides us with a means of ensuring that the refactoring hasn’t broken anything. Refactoring and unit testing are made for each other: I will cover refactoring during my session and Dr.Bob will cover unit testing in his.

Attend this session if you want to learn how to be more productive within the Delphi IDE (Win32 or .NET), how to be more responsive to your customer’s [changing] needs and how to bring your application to market faster thus encouraging an early return on investment and realising profit sooner rather than later.

XML and Web Services
Between Delphi 6 and Delphi 2005, the bottom line functionality of Delphi’s support for protocols like the Simple Object Access Protocol (SOAP) and web services hasn’t really changed very much. Granted, there have been bug fixes and upgrades to support newer versions of World Wide Web Consortium (W3C) standards, but if you look at the applications that can be created using Delphi, not much has changed.

So why spend 45 minutes talking about it?

Well, there are plenty of good reasons, least of all:

1. Delphi 2005 could be the version you have been waiting for: a lot of folks follow “odd numbers”, Delphi 3, 5, 7…Delphi 2005 is the next logical version. If you plan to adopt Delphi 2005, and you are coming from Delphi 5, then it is possible that your Delphi 2005 application architecture will need to involve web services.

2. Delphi 2005 could be the version that you plan to “migrate to .NET” with. You’ll need an understanding of what’s in .NET that can help you: this session will provide you with an understanding of how to integrate your application(s) using .NET’s XML support and will show you how to interact with other applications running elsewhere on the Internet.

Building applications that rely on web services to serve up their functionality might sound odd. However, think about how your existing applications are architected: you probably use “layers” or abstractions to shield GUI functionality from database access functionality, for example.

Building an application using web services instantly gives you a layer of abstraction: you can implement functionality once, and then use it from a GUI client application, and web client application or even a mobile device – anything platform that is capable of consuming a web service could potentially become a user of your application.

This suggests that your application could be used in more remote locations….increasing the return on investment and bringing your application into profit much sooner.