Programming

Human sorting algorithms

2011-06-11T16:37:00.005+01:00

Whilst tidying the shed, I had to stack around 100 plant pots. This is a straightforward sorting algorithm.

So why don't humans use quicksort, like computers would?

The answer which occurred to me was that the effort to compare two items is not always equal. The other answer is that humans can't keep track of umpteen piles of stuff, and remember which pile needs to be merged into another pile. Each of these things takes overhead which isn't accounted for in the traditional analysis of sorting algorithms.

When there are a small number of possible sizes, the correct algorithm should be bin-packing. Just keep n separate piles, and put each item into their pile. As the number of sizes is small, arranging them is easy.

The algorithm which I used is as follows: spread everything out and pick the biggest and put it onto the pile. Repeat. If you make a mistake, do an insertion sort. This is efficient for humans, because our eyes are great at parallel processing, and is fine for around 100 pots.

Now, how to prove that this! Another real-life problem where the correct algorithm isn't obvious, is matching socks. In this case, the problem is finding a decent way of comparing them. I would suggest using a bin-packing algorithm to start with, and going from there. At each layer in the hierarchy, pick an appropriate discriminator.

What sorting algorithms don't analyse either is the likelihood of mistakes, and the cost of correcting them!

Why virtualization is pointless

2008-06-03T23:24:00.002+01:00

Virtualization is a growing trend in running computers in "containers" which emulate (virtualize) actual hardware. The benefit is that the container becomes portable, and can be run on different hardware, or migrated. Backups are a lot easier, there are security benefits, and hardware can be utilized more effectively. Virtualization is a growing trend and Microsoft has realized this and put it at the heart of Windows Server 2008.

The heart of the web - URLs (uniform resource locations) are a specification of the location of a resource - usually a web page, but can also refer to services (e.g. SOAP) and web applications.

The real problem is that machine name is being used as a proxy for resource location. In a URL - e.g. http://bbc.co.uk/news/12345.html - the bbc.co.uk part is specifying something physical - often a machine name - but certainly a physical place such as a router. In computer networks, machine name is critical in specifying the location of certain resources. This is the legacy of DNS (domain name system) which assigns names to computers.

Physical device is often used as a proxy for resource in the home. Your photos are stored on a physical disk in a physical computer, and you locate them by specifying where they are stored. When you are out and about, you usually don't have access to them because you don't have a network access to the physical device.

This approach of tying resources to hardware is frankly wrong. Why should I care where my photos are stored - providing I can access them and they are stored securely. Maybe hard disk or memory should be an intelligent cache and nothing more. The current approach does not protect users from data loss, and is hard for users to manage.

Virtualization is a solution to the wrong problem. Virtualization allows the easy migration of a machine - but why would you need to do that? It's only because we rely on certain services running on certain machine names that we even need to think of the "machine" as a unit. Virtualization is incredibly wasteful of machine resources, and is like hitting a walnut with a sledgehammer. It's far better to migrate the software, and have multiple software running on the same OS - like the good old days. We already have a perfectly good container, and it's called the "process".

The solution is to break the link between resource and machine name. I predict that in the future, data, services, resources and computing resources will exist in a redundant, replicating, self-healing "cloud". Running processes will be able to migrate between different computers - much like they can migrate to different processors at the moment. Different computers will form collectives and be given a catchy name like "swarm", "hive" or "cluster". In future, we will think about services, rather than physical or virtual machines. Virtualization is merely a stop-gap measure until we fundamentally rethink the way we provision resources.

Vista isn't as bad as everyone says it is

2008-04-02T21:15:00.002+01:00

It's much worse than that.

I've just been waiting 20 minutes for my 64-bit quad-core RAIDed desktop to boot. I think I'll just have 30 minutes of work - and almost all of that time is lost to Vista hanging and crashing. This is about the 10th time my computer has hung up like this. The only reason I go with Vista is because we use the Microsoft toolchain at work which I quite like, and I foolishly think that I'll save time by using Vista. I mean, if it's one thing an OS need to be, it's stable. The kernel seems deadlocked and resource starved. This is SP1.

Other niggles are that its safe boot won't recognise my USB keyboard (even though the BIOS does), it hung and didn't work with my Wifi card (so I had to waste money on a new one). It bugs me about UAC each time my computer boots, and the whole kernel is very unstable coming out of hibernation. Each time I reach for the reset, I know my computer will be out of action for hours whilst it verifies its RAID. Really, Linux is looming.

* Harp music and a mirage *

Steve Bulmer (no relation to the fat fuck at Microsoft) is sitting on a park bench. Suddenly a 500kg gorilla grabs him from behind and...

* More harp music *

Ah, Vista shows me a logon screen. All is well. Next time Vista plays up, I'll start having fantasies about Bill Gates and a pack of hungry wolves.

Speeding up builds

2008-03-23T13:17:00.003Z

Here's a really simple tip if you are using GNU make. You can pass in the -j option to run the build steps in parallel. The default is -j1, i.e. no parallising.

The next question is what's the optimum number of jobs to run in parallel? An experiment on a build reveals:

N	Time
1	6m13s
2	3m28s
3	2m38s
4	2m11s
5	1m59s
6	1m55s
7	1m53s
8	1m49s
12	1m47s
16	1m47s

So there you have it! On a 4-core CPU (Intel Q6600), it's best with -j4 or above. It's interesting that -j4 didn't max out the CPUs, and that you can keep getting good improvements up to at least -j8.

Why isn't visual programming popular?

2008-01-17T19:49:00.000Z

Visual programming is the idea that programmers (or even end-users) can program using a graphical notation. There are a number of reasons why this seems like a good idea:

Programs are structural, not linear/sequential
Textual syntax is difficult, and a barrier
Graphical notation is richer - allowing new paradigms that would not work with text
Direct manipulation - treating program components as physical things
Programmers use graphical notations widely, both formally and informally

Of course visual programming hasn't actually taken off as expected. A lot of excuses have come up. Here are some of them:

Yea, but we're stuck in a textual programming rut
Almost all new programming languages fail; this is to be expected
Workstations aren't graphical (not true any more)
All VP systems are toy systems unsuitable for real world problems (true to an extent)
Graphical notation is less compact (true, but there are solutions)
Because early VP system sucked, people assume all VP systems suck
Graphics is obviously better, we just haven't found the right approach yet.

Until recently, I would have had a great deal of sympathy with these views.

I've recently been working with use cases, which are a predominantly textual notation. The interesting thing is that there is also a graphical notation for use cases. The problem with the graphical notation is that it loses all precision, including extensions, preconditions, actors, goal level, stakeholders and interests, guarantees etc. In fact as a notation, UML use cases diagrams are very poor in comparison to text.

So we need to accept that fundamentally, some information is best presented as text.

Another problem is that the notation isn't as important as other aspects of software development. The text editor is just a convenient universal editor. It isn't the syntax which is hard with programming. It's annoying, sure, but it's not the crux of the problem. The crux of the problem is the design, the OO model, the functionality, memory allocation (if using C), the algorithms, the usability, the process, and the obsessive (male?) thinking. These are problems that aren't going to be changed by a graphical notation. In fact, using the text editor is probably the easiest part in the whole programming process!

What are the lessons from Visula?
In some ways, Visula is yet another VPL. A large part of it was written for fun - what would I come up with? In terms of scalability and practicality, it is orders of magnitude better than many other VPLs. If the question was: can VPLs be practical, usable and scalable, then the answer is a resounding YES! I didn't know this before. Hopefully that blows away some of the old prejudices, if anyone will listen.

Visula will not become a mainstream language though. It doesn't offer huge benefits over other scripting languages. I personally prefer the notation (which is really unique by the way), but that isn't enough on its own to persuade people to switch. Also the editor only runs on Windows, big mistake.

In hindsight, I should have based Visula on an existing scripting language, and created a graphical editor for the language. This would have been simpler to implement, and users would have no barrier to entry for the new notation. If they decide they don't like the editor, they can switch back to text. Creating a totally new language that nobody's going to use is fun, but pointless.

Recent trends
Before discussing new trends, let's review the current trends.

Types: Strong -> Dynamic
Style: Algorithms -> Glue
Data: Bits and bytes -> Objects and patterns
Expertise: High -> Low
Environment: Textual -> IDE -> Tools
UI: Text -> Desktop -> Web -> Web 2.0 -> Web apps.
Data: Files -> Databases -> Mobility -> Sharing -> Community
Paradigm: Procedural -> OO
Memory management: Manual -> Automatic
Data binding: Manual processing -> Drag and drop
Databases: File -> Relational -> ORM
Software: Small and buggy -> Big and bloated
Quality: Low -> High
Development process: Waterfall -> RUP -> Agile
Interoperability: None -> Low -> Inherent
Programmers: Generalist nerds -> Specialist communicators
Usability: Terrible -> Low -> Better
Platforms: Single platform -> Run anywhere. Desktop -> Web -> Mobile
Libraries: Small and fragmented -> Monolithic and comprehensive
Formats: Binary -> Text -> XML
Automation: Low level languages -> Code generators -> High level language
Reuse: None -> Libraries -> Platform

Future challenges
We still need to explore new notations - not because they are useful, but because they are interesting. It seems that all new work in HCI has to have proven immediate benefit backed up by experiments. This isn't blue-sky research, this is short-termism. Researchers should avoid making optimistic claims about the usefulness of their approach, but then they shouldn't need to.

There are a number of upcoming challenges to programming that software tools in general should address.

Scale. Libraries are now tens of thousands of methods large. How does one manage such a large amount of data?
Parallelism. We hear this all the time.
End user programming. Includes teaching programming to kids. How does this translate into grown-up programming?
Integrating programming with development process. Done in CASE tools. But there is a disjoint between CASE tools and programming languages.
Tracking, collaboration.
Web-based programming.
Textual transformations.
Reduce detail.
Navigation.
Searching.
Make it tangible.
Specify less.
Manage detail.
Guide the user. Often you stare at some code asking "what do I do next?"
Create a top-down workflow where the programmer assists the tool, not the other way around.
New paradigms. If I knew what they were, they wouldn't be new would they?
Hide complexity.
New abstractions, e.g. for parallelism.
Reduce cognitive load. (A posh way of saying make it easier).
Focus on the domain and the goal - not the technology.
XSLT or other transformations between notations.
Raising the level: Making programming more human and less nerdy.

What's clear is that transforming the textual notation alone isn't going to address these challenges. It might look pretty and nice, but it's not where the trouble with programming lies. I'm optimistic that graphics are better, but they are also a bit of a red herring.

As Fred Brookes said: There is no silver bullet. There is so much more research to do. Programming as we know it will change. I just wish I was clever enough to work out how.

Write more libraries

2007-11-18T21:20:00.000Z

We keep hearing that code reuse is a Good Idea, that we should do more of it, and that it can drastically reduce costs etcetera etcetera. It makes common sense in an ideal world.

The reality is very different. Code gets build into applications, dependencies build up, behaviour becomes fragile, code becomes less maintainable, and eventually after the people who wrote the code have moved on, decided that the original design was poor, the maintenance costs rise and becomes a fire-fighting exercise, so the code gets thrown away and rewritten. However this can be a cycle: new code eventually also rots and gets thrown away.

Refactoring is supposed to rejuvenate your code and keep it current. I'm sure the theory works fine.

The problem is that fundamentally, people don't write code for reuse. They put a good design in (that is appropriate at the time), and think that's the end of it. However that code won't get reused properly. It might get ripped out and copied-and-pasted into another application, but that is far from ideal code reuse.

Instead I would suggest putting as much code as possible into reusable libraries. This means that as much as possible should work stand-alone, without dependencies. When coding a library, imagine its use for the application at hand, but also treat it as an independent work, with proper documentation, and proper anticipation of the different ways the code could be used. It may mean generalising prematurely, but the code becomes infinitely more useful.

Now in a typical project, I would organise it as follows:

lib1
lib2
test1
test2
applogic1
applogic2
testapplogic1
testapplogic2
app1
app2

lib1 and lib2 are the main code - as independent libraries, They depend on nothing, except perhaps each other (and without circular dependencies). Most of the code should go into these libraries, and follow proper documentation and coding guidelines as appropriate for libraries. Where specific implementations are mandated, try to provide a strategy pattern to make the library not specific to the application. Where code is too interdependent, break the dependency by providing interfaces.

The test1 and test2 projects are the unit tests. These test the functionality in lib1 and lib2 respectively. Part of the build process should be to run the unit tests, and fail the build if the unit tests fail.

applogic1 and applogic2 are libraries of business or application logic (you could also have bl1 and bl2 if that suits your application better). There are also unit tests for applogic1 and applogic2, which should also be run as part of the build.

app1 and app2 are the different applications. The point is that app1 and app2 should be as thin as possible. This is the bit you're going to throw away or port to another platform, whereas everything else should be cross platform. app1 and app2 can share common functionality from lib1 and lib2, and the logic from applogic1 and applogic2.

In terms of longevity, app1 and app2 have the shortest lifespan. They will be full of platform-specific GUI-code which will be hard to unit test. applogic1 and applogic2 contain logic specific to your application, which can be shared between applications. If possible, make the logic extensible without going over the top. The application logic will have a longer lifespan because it can be reused for different applications, but is in general tied to particular applications. The libraries should have an indefinite lifespan.

If you are serious about code reuse, you should push as much code as possible into libraries. Think: does this unit have functionality beyond the application? Can it be generalised? If the answer is yes, then move the code into a library.

In hindsight, I don't see how any code could be reused unless it is in a library, and I don't see how unit tests can be linked against code embedded in an application. Librarifying (!) your code clearly separates out the parts that you intend to reuse, and the parts you intend to throw away. Libraries are your crown jewels.

Reversing the #include idiom

2007-10-11T11:20:00.000+01:00

There's an idiom in C and C++ whereby of you include a header file, you write

#ifndef FILE_H_INCLUDED
#define FILE_H_INCLUDED

// stuff

#endif

It occurs to me that it should actually be

#ifndef EXCLUDE_FILE1_H
#define EXCLUDE_FILE1_H

#endif

This is a minor point, however it means that you can legitimately exclude certain header files if for some reason you don't want to include them:

gcc foo.c -DEXCLUDE_FILE1_H

New user interface rule

2007-09-29T21:10:00.000+01:00

Every action on a user interface shall result in a response from the computer in less than 0.25 seconds.

If the operation would take longer than 0.25 seconds to complete, the computer shall clearly indicate that it is processing, and not block the user from performing other tasks while the initial input is being processed.

This shall be guaranteed, no matter how busy the computer is, no matter if DNS or some other network service hasn't responded, no matter how much the disk drive is being thrashed, how little memory is available, whether you are compiling, or some other USB peripheral has decided to take a while to spin up a disk or generally hang.

The reason is because my biggest bug bear is devices not responding. The worst kind of hang is on a slow network. It drives me absolutely nuts that developers can't anticipate that maybe, just maybe, DNS or something else might get knocked out for a few minutes.

A new filing system

2007-09-22T10:17:00.000+01:00

I was recently reorganising some files, and getting quite annoyed with how difficult even simple filing system tasks are. It occurs to me that the current filing systems are really badly designed from a user's perspective. For example

Knowing where stuff is is a nightmare
Disks get full
Data is always on the wrong disk, never where you need it
You copy to move it about. The two copies get out of sync.
It's not backed up
It's not securely stored
You need to delete junk occasionally
Data get duplicated, sometimes a lot.

Of course there are point solutions to all of these problems, but none I could really explain to my mother. The problem is that files are still presented to the user as they are stored on disk, not how the user uses them.

I think every data (or file, if you must) should have a URL, e.g. my photos would have a URL

file://calumgrant/photos/namibia-2007

Each file, or possibly each folder needs a simple policy, including

Lifetime: e.g. 1 week, 1 month, 1 year, permanent
Confidentiality: e.g. me only, work, friends and family etc
Portability: This machine only, This network, internet, mobile device(s)

If I plug a new hard disk into my computer, I want it to be used automatically. I just want to specify whether it's a permanent hard disk or one I take away (and where). If I specify data as portable, I want the data synced to the right places automatically. If I decide to remove a hard disk, I want the data to be moved off it automatically. If I mark stuff as permanent, I want it backed up silently and automatically, perhaps to an ISP or a backup drive. I want revision control so I (or a virus) cannot trash my data.

I think we may be entering a new age of usability. I really hope that users start getting a better deal soon. Computers should be much more geared towards the way users use data, not how it works underneath.

Savaging Adobe's XMP-SDK

2007-08-22T17:51:00.000+01:00

This is an official "commercial" API/SDK from a very respected company producing "high quality" software. So far, it has been adequate quality rather than high quality.

The first problem I encountered was that it isn't GNU friendly, in that it lacked a configure script. This means I need to go digging in documentation to see how to build it. Fortunately there was a Visual Studio solution file, and once I had loaded it into VS (and fortunately I had the right version), it built okay. The use of third-party libraries went pretty smoothly. The problem is that the documentation is strewn all over the place in a variety of txt, HTML and PDF formats. What I really need is a step by step idiots guide, not because I am an idiot (I hope), but because I am busy and do not care to understand a new build layout.

There was also no example code, and no tutorial. You just get the methods documented. Both of these would have helped a lot.

There was a slightly unconventional inclusion of XMP.incl_cpp - a way to get templates to compile. Not bad, but this information was buried in the documentation (which I am too busy to read), hence I wasted a lot of time.

I really like a single XMP.hpp file included, but there is include hackery. This information is also buried in Doxygen comments, and it is pretty ugly to require two macros. Instead of saying #include , I need to write #define XML_INCLUDE_XMLFILES 1. Wrong-headed. I also need to #define WIN_ENV. I just shouldn't need to do these things.

You also need to pre-declare TXMP_STRING_TYPE for some reason - which completely negates the benefit of using templates. I could just write typedef std::string xml_string_type.

My next issue (due to lack of tutoral) is a strange assertion which I trace back to me not calling TXMPFiles<>::Initialize(). Argh. This is to initialize global state (which is evil). I also notice that all types start with a T. Not a C, a T. There is no namespace. Names are in CamelCaps - fine but not C++ standard. Finally I notice the opportunity for two-phase initialization (or 3-phase, if you consider TXMPFiles<>::Initialize()). Errors are indicated with return values, not exceptions.

In conclusion, this is falling into all of the old C++ traps that I would have imagined that modern libraries (and this library has been revamped fairly recently) should have avoided. It is clearly a C/C++ hybrid. Commercial software 0, open-source 1.

2007-07-24T23:32:00.000+01:00

26 ways to write Hello world!

In my latest article, Demystifying design patterns, I apply some design patterns to the Hello World program. For beginners this is a useful tutorial in patterns. For advanced programmers, it is an amusing new look at Hello World.

2007-07-04T22:39:00.000+01:00

The 10 commandments of C++

1. Thou shalt use an automated build process with no manual steps
2. Thou shalt run automated tests with every build
3. Thou shalt avoid short or cryptic names
4. Thou shalt avoid avoid embedding constants and data within code
5. Thou shalt see when things get too big, and thou shalt split them
6. Thou shalt document every function
7. Thou shalt analyse defects for their root cause
8. Thou shalt use standard containers liberally, and avoid pointers.
9. Thou shalt write exception-neutral code using RAII
10. Thou shalt write for reuse.

2007-05-29T20:55:00.000+01:00

C++ Units library

I've spent the past week constructing a units library. I have always wanted to do this. I am extremely pleased with the result. Here it is:

http://calumgrant.net/units

2007-01-10T12:10:00.000Z

Never use built in types

This sounds really daft, but it is not. A lot of programmer errors are caused by confusion about values. For example, assigning an address to a name. Was the value in minutes or seconds? To make matters worse, C++ actually encourages implicit conversion between types, and the programmer needs to go out of his/her way to make constructors explicit to prevent this conversion.

Another problem is documentation. If a function takes an "int", there is little clue about the semantics of the value. The meaning must be elaborated in the function name, parameter name or documentation.

A large class of error is caused by programmers passing the wrong kind of value.

Another problem is the premature commitment and viscosity (to use CD terms) of one particular build-in type. Suppose you write an application to use char, then realise that you really wanted a wchar_t. You would need to change every instance. Not a problem but a hassle.

The solution
You would think that using a typedef would aleviate some of these problems. e.g.

typedef int seconds;
typedef int minutes;

This helps a lot but does not prevent mistakes when converting between the two. So you create a class

class Seconds
{
public:
explicit Seconds(int value);
int operator*() const;
};

This is fine but is a lot of work to introduce a new type. Instead I propose to tag each value with a type, as follows

template
class tag_t
{
public:
explicit tag_t(const Prim value &= Prim() ) : m_value(value) { }
template
tag_t(const tag_t &v) : m_value(*t) { }
const Primitive &operator*() const { return m_value; }
private:
Primitive m_value;
}

template tag_t tag(const Prim &p)
{
return tag_t(p);
}

Examples

struct SecondsTag; struct MinutesTag;

void setTime(tag_t mins,
tag_t secs);

setTime(tag(12), tag(0) );

Next
This is turning into a units library. We should see how we can extend this basic implementation to deal with multiples and conversions.

2006-12-09T14:20:00.000Z

Software features

I am trying a new experiment. I am trying to create a list of "features" that one of my libraries has. So I am labelling each feature something like

// features.parser.parse_narrow_cstring

Roughly, each method, class or usage gets a feature. Normally, each feature requires one unit test, and if a feature has different behaviours requiring different unit tests, then I will subdivide the feature.

I must also make sure that somewhere in my unit tests, I include

// features.parser.parse_narrow_cstring.test

Hopefully this will give better unit-test coverage, and allow me to document and structure the library better. It will also allow features to be cross-referenced to code more quickly.

Hopefully this will make my code better organised. I shall report on whether it works.

2006-12-01T11:57:00.000Z

Free VMWare server

I was initially really excited to see that this was a free product. It would solve a lot of my problems.

Having used it for almost a day (most of this time was spend waiting at an unreponsive computer) I have completely given up. My computer is completely unusable. It has 1GB of memory, and my machines were running on a second hard disk, so it should be able to run at least one other OS without causing too much difficulty. Not only does the emulated OS run quite slowly, but then my *real* machine ground to a halt as well.

It takes about half an hour to boot Windows Vista. Every key click takes about a minute to react. My mouse cursor (on my real OS) hangs.

This is totally unacceptable. What a pity I will never use this product again.

2006-11-30T15:07:00.000Z

Customizing user interfaces

In the same way that resource files are customised on language, they should also be customised on user. This is almost like theming, except that it really applies to windows text. For example you would have advanced users who require a minimum of text, and novices where all the buttons are quite verbose.

2006-11-17T16:35:00.000Z

Today I came up with something really clever - or so I thought. I was trying to determine whether one class was derived from another, but not having much luck. The following solution struck me at 2am last night:

template
class is_derived_from
{
typedef char success;
struct failure { success x[2]; };
static failure f(void*);
static success f(Base*);
public:
static const bool value = sizeof(f((Derived*)0)) == sizeof(success);
};

Unfortunately I googled around a bit and there is one place where this has been invented before, almost verbatim. Darn.

2006-11-14T21:50:00.000Z

Home server

I have recently bought a Linksys NSLU2 for under £60. This is a networked storage device where you can plug up to two USB hard disks in, and an ethernet cable. The box can server files via SMB and FTP.

The fun starts when you install Linux on it. Some very keen hackers have written instructions on how to "extend" the system by installing your own software on it. You can upload different firmware which gives you proper telnet access, and there is a package system where people have pre-built a load of software for you to install on it. The box runs at 266MHz, and the software runs from your hard disk.

I have a 250GB disk attached, and am running Apache 2, Subversion, OpenSSH and a very nice iTunes server. This means that my entire music collection is available to all of my networked devices, e.g. iTunes and my Roku wireless media player. I also have X11 and gcc, and a load of other GNU software. Coupled with dyndns.org, I can have a webserver with a fixed address.

This is a very cheap way to set up a home server, and is much cheaper and more satisfying than leaving your computer permanently on.

2006-10-06T09:47:00.000+01:00

Staying on-task

One of the major faults with Microsoft Windows is that you can get interrupted by lots of little Windows popping up. E.g. if you start an application, it can take a while for it to display, and in the meantime you are busy typing something else. Then there was the recent example of an anti-virus subscription notice popping up during a Powerpoint presentation.

This is clearly wrong. When you are doing something, nothing short of hell or high water should interrupt you. You should never ever be typing something, then some other window pops up and steals the input focus, and then midsentence you start typing commands into this dialog box which then closes and you feel uneasy that you may have just done something drastic and irreversible.

Whilst I like Windowing systems, I can't help feeling that most applications really should run full screen, with a notification area on the bottom in case something drastic happens (like you get a new email). The problem is that the Windows taskbar is cluttered and poorly configurable. Everything is so noisy and distracting. Just looking at my screen, I can see 165 different things I can click on, and a lot more if I opened any of the menus. I want to see nothing but the task I'm on.

I see the next big thing as being task-oriented user interfaces. Everything you do will be focused on performing, and guiding you through a task. This does go slightly against an exploratory approach, however you won't need to do so much exploration if the tasks are set up right.

2006-09-28T16:24:00.000+01:00

A new VPL based on AOP

I've been reading about aspect-oriented programming (AOP), and had it explained to me that concerns "cross cut" methods. Then John put his fingers together in a mesh. This was a bit of a kerchink moment. You could create a visual programming language (VPL) in which aspects are displayed on the y axis and methods or functions are displayed on the x axis. This would show very clearly which functions had which concerns.

2006-09-08T10:43:00.000+01:00

HCI Considered Harmful?

I've just come back from VL/HCC 2006 having presented a short paper on one of my pet projects: Visula. Here is the paper, and here are the slides.

Overall it was a very positive experience. I find the general area interesting - if the conference was a bit cheaper and always in the UK I would want to attend every year.

What surprised me a lot was the amount of end-user and novice programming. The papers were roughly divided into spreadsheets, learning through play, visual support for developers, and a little bit of visual parsing.

One comment is that it is a very applied subject. Everything follows the same pattern: here is a problem, here is a tool to solve the problem, we gave it to some users, here are the numbers. This is actually pretty boring! The field does not seem to have moved on very far. I think the mass of papers is because everything is done in finiky little steps. No fundamentally new ideas were presented in the entire conference, and I had no "aha" moments. Everything had to be proven to be of real benefit to a group of users, which is certainly not blue-sky research.

A problem I see is that the word "programming" and "software" isn't used in the conventional sense, and I would much rather see the term end-user development or engineering. I see this as a ploy to place these subjects into computer science where funding is more plentiful, even though this is strictly speaking interdiscpinary with accountancy, [software] engineering, psychology or education.

I particularly enjoyed was the "how-to" session: how to do research, how to write a paper, how to transfer technology to industry. The guidelines they gave were completely idiot-proof. I definitely learned a lot, and wish my PhD supervisor could have told me some of those things.

The best paper award, by Christopher Hundhausen et al was very good because it fitted the formula well. It really brought out the questions and hypothesis clearly, its references were complete and had good coverage, data was collected well, strong statistics, and tackled an interesting question. The work itself was secondary - it was okay I suppose!

The keynotes Ron Baeker and Thomas Green were top-notch, and my opinion about Thomas Green improved from irritating pedant, to warm, clever, insightful, interesting and entertaining. Pioneers have a certain charisma and drive that keeps them going for so long - qualities to aspire to.

In Thomas's keynote he proposed that we should specify almost nothing, since then we don't have the problems with specification. At first I thought that this was stupid - that surely just leads to ambiguity, and where computers use their intelligence, they get it wrong. But less specification does not necessarily lead to ambiguity, and computers can indeed outperform humans in many areas to fill in the gaps for us. An example: typed languages. Thomas implies that we shouldn't specify types in our programs, we should leave it up to the compiler. I couldn't agree more!

Instead I would say "specify as little as possible, but no less". Whenever we specify anything, it is because the computer can't fill in a gap. But all too often we tie our hands unnecessarily. As computers have gotten better (for example at generating machine code), we are able to leave out that part of the specification and work in high level language.

Often we imagine we really need that extra bit of complexity, when actually we don't. This is just "less is more". The more computers can automate, the less we need to specify things on them, until eventually they'll stop plaguing us. In fact, the thesis should be "HCI considered harmful", and the less interaction with computers we need, the better. I digress.

Both of the keynotes actually supported my work - Thomas by suggesting that a stave notation was truly beautiful, and Ron by suggesting that visual programming was a worthy goal. I clearly need some pictures of vines and horses around my visual programs, on a parchment backdrop. I think Ron actually said this because he believed that's what we wanted to hear, even though many researchers have given up on the idea as too problematic.

It was very difficult to get people really engaged about visual programming. People were always mildly positive and interested in my work, but I met nobody who was passionate. Talk went well - I always come across a bit nervous at first which is why it is good to make myself talk since I actually enjoy it. No tough questions - Erwig asked whether the + operator was overspecified since it is symmetric. My answer is that this was a problem in text as well, which was completely the wrong answer. The + operator is not symmetric, e.g. on strings. People were positive that someone was actually working on VP still, and I think people bought my argument that the benefits of sequence diagrams could be transferred into programming.

If I really wanted to take Visula forward I would have to round-trip to a language like Java. The problem is that the languages are quite different and it would be like trying to stick a square peg into a round hole. We shall see.

My other motive for going to this conference is that I really want to get into spreadsheet "programming". A friend of mine currently does business modelling on huge spreadsheets, and wants a better way. Nothing at the conference came close to solving the problem of managing large spreadsheets, so there is definitely an opportunity to develop something.

2006-09-03T14:13:00.000+01:00

Human-centric computing??

I am now ready to go to the conference (VL/HCC 2006) and present. I have managed to squeeze the talk down into 12 minutes.

I have come to the conclusion that nobody cares about visual programming. This is evident from the complete lack of implementations. It was also clear that only one of my reviewers (of the three) knew anything about visual programming at all. None of them bothered to look at the website or try to use the software.

To make matters worse, the next conference (VL/HCC 2007) does not even include visual programming or languages on its list of topics at all! I can clearly see that they will rename the conference to HCC'08 in the future.

It has been argued that visual programming is more suitable for end-users and novices. That is fine, except for the problem that most programming in this world is done by experienced programmers. It depends on what you mean by "programming".

The VL-part of VL/HCC hasn't happened because the world has so much invested in textual languages. After a while, people concluded that VPLs don't work. This is not true, they just haven't been available. When I set out to create Visula, my starting thesis was that it would suck and wouldn't work. But guess what - with a bit of experimentation I created a system that worked absolutely fine.

If you think about it, nobody is actually going to create new VPLs. Final-year project students aren't going to because the task is much too large. University research projects aren't because researchers aren't usually that experienced at programming, and nobody could get funding for such a project. Companies aren't going to create VPLs because there is no money in writing new programming languages. That leaves the open-source community, who do it for the love of it.

It will be interesting to see if my opinion about human-centric computing goes up or down after this conference. I will also see if I can meet anybody who actually gives a damn about visual programming. It was such a hot-topic 10-15 years ago, now where has it gone?

2006-07-05T19:01:00.000+01:00

Classes should be lazy?

Today my tech lead announced that classes should be lazy. WTF I hear you cry! Google for that and you'll find nothing. I think what he was trying to say is that classes should have clear, well-defined and limited responsibilities.

I think he means classes should be selfish. Which means encapsulated in English. Here is an article describing selfish classes, though it is about the only Google hit.

2006-06-26T17:46:00.000+01:00

Never, ever ever let Microsoft manage your partitions. I made a fatal mistake of clicking "upgrade volume to dynamic". Not knowing what the true horrible implications of this was, I foolishly clicked "yes". No warnings that this was an irreversible process. Then suddenly had to reboot. The machine blue-screened first time, until I went into partition manager to fix it. It now boots fine.

However the disk is now borked in a proprietary format that I can't do anything with except wipe it and start again. I can't find the "dmunroot" utility which wipes all other partitions anyway.

Luckily it is my spare machine, but it will take ages to set up again.

Microsoft's attitude is "why would anybody wish to downgrade?"

2006-06-26T12:11:00.000+01:00

A comparison of programming paradigms

Why is object-oriented programming (OOP) so popular?

It is often said that OOP "models the real world". I would argue that this is not true - OOP models the way we think. That sounds radical, however the way we perceive the real world is via the way we think, so there is not such a huge difference after all.

OOP also models natural language. There are nouns (objects), verbs (methods/functions), adjectives (properties) and adverbs (parameters). Natural language is also closely related to the way we think.

Functional programming is more abstract, because although solutions can be more elegant, it does not lend itself quite so naturally to human thought. People think in terms of concrete things that they can push around, so stateful languages are therefore easier for our brains to manage.

Logic programming languages are even harder to write complex algorithms in. The problem as as soon as you have recursion, your head needs to start abstracting again, and it's difficult to visualise too many things at once. At least with functional programming you have inputs and outputs, which are concrete things - with logic programming you have partially-filled in inputs and outputs and algorithms can frequently be run in reverse.

For expressing simple problems, logic programming can express things very nicely, since effectively the program and the data are combined. Predicates are data that are executable. However you still need to understand the execution model and backtracking to achieve non-trivial tasks, and this is where logic programming falls down. For example, implementing a merge-sort algorithm in Prolog (which I have done) is very satisfying but I can't help thinking that it is out of reach for the average programmer.

For simple, declarative tasks, I don't really consider that to be programming since there are no algorithms involved. I would not class data transformation as programming (though it is of course an extremely useful activity).

Imperative styles, do A, do B, do C, are pretty easy for our brains to manage. Therefore, scripting languages, and procedural languages are pretty popular. However OOP takes this one step further by creating objects that react to things, rather that data which is operated on by a procedure. Objects reacting to things is an easier way to think about things since it models our own perceptions of the world.

I therefore argue that the relative popularity of programming paradigms comes from the ease at which the paradigms can be used, which in turn comes from how natural we find the language. If you require an IQ > 130 to master a paradigm, perhaps the paradigm isn't so useful after all.

2006-06-21T12:03:00.000+01:00

About a week ago, I was wanting to assert whether a piece of code was running inside a database transaction. My suggestion to my tech lead was: why not use the type system to ensure we have a transaction object.

The response from my ever curt tech lead was: we don't need to know that. Stupid me.

Today my wonderful tech lead suggested that we use the type system, and looked very proud of himself. It's nice to know my emails just get ignored.

2006-06-16T10:08:00.000+01:00

Usability?

I've recently tried to submit my paper to VL/HCC 2006. The good news is that I got a paper accepted, the bad news is that it's only a short paper, the conference is quite expensive and seems to last all week. So this is larger dent out of my money/holiday budget than I wanted. Still I've worked on Visula for a while (as a background task) so it makes sense to write it up. On the brighter side, I don't need to talk for so long :-/

So today is the deadline. I've been very quiet recently since I've been trying to condense 8 pages into 4, and now it's ready.

The instructions to submit the paper are long and infathomable. The login process is protracted. The links in the page have broken icons. A link to submit the paper is missing. An instruction to fix the link is also infathomable and refers to boxes that don't exist. The upload process is slow and error-prone. The PDF verification process has a really shitty UI. After a few attempts, I get my PDF verified. The submission link just takes me back to the start. Then this morning, the entire site has crashed due to lack of disk space on the server. I still have no fricking clue how to submit the paper, I'll randomly click some more when the server comes up. I emailed the tech support yesterday with no response.

My next usability hurdle comes when I need to register for the conference. This website seems nice and clean. I enter a few details, hit a button and get a blank screen. Bam. Nothing. Try again, same result. Apparently I should fax a non-existent registration form to a non-existent fax number.

Now, the irony of the situation is that this conference is concerned with usability and human-centric computing! Still it's not too late to withdraw...

2006-05-30T16:38:00.000+01:00

This guy is an ass

Nobody understands this guy when he talks. He'll make up words and phrases, and say them with such a straight face that you have to believe him. His designs are incoherent. He is a maverick. Because nobody understands what he says, he thinks he is incredibly gifted. The actual reason nobody understands what he says is because he is an idiot.

2006-05-18T10:02:00.000+01:00

Clippy is the worst piece of junk I have ever encountered.

I asked a simple question: "How do you update all fields in a document?"

The answers:

Troubleshoot templates and letters
Field codes: Autotext field
None of the above: search for more on the Web

That is the most pathetic attempt at help I have ever seen. I don't want an animated paperclip, I just want to update my fields (which incidentally should happen automatically anyway). Clippy remains fun for about 2 seconds. I think given the quality of the answers, he should be replaced by a cripple in a wheelchair - if you could wheel him around the screen I would probably find that more entertaining.

2006-05-10T22:42:00.000+01:00

Trying to move a computer

We get a new PC. Hurray!

The trauma begins. Endless cycles of downloading updates, and rebooting every 5 minutes. Have MS still not solved the problem? Next, trying to copy data from one PC to another. There's this piece of junk called "File Transfer Wizard". For some reason, it requres to be installed on removable media - huh? I have a network thankyou. Don't have removable media on desktop. Eventually find an SD card, and an SD card adaptor for the old laptop. Guess what, the reason we're upgrading is because it is an old piece of junk with not many ports... Anyway eventually we coax it to running, and eventually we coax it into copying files onto a network share. For some reason it decides to back up the entire hard disk, including all of the photos on the SD card. Takes hours and several attempts. Run the File transfer wizard on new PC. It refuses to recognise the contents of the share.

Next step - try to copy the Application data directly. Works kind-of, except that the length of a filename is exceeded and Windows 98 truncates it. Can't copy that way. Download two different zip software, try to zip up the data. Both result in corrupt ZIP files. Attempt to export Outlook express data - fails miserably. Tries to export the data to Outlook on same computer. Run Outlook, export data from that.

Now try to copy Outlook data across network. Win98 decides it's going suddenly and sponteneously fail to browse the network. It is teasing me with its smug red little computer icon.
Finally, copy onto SD card, copy to other laptop, copy across network, and import. Success!

2006-04-27T20:54:00.000+01:00

I don't normally talk about work, but today I had a two fantastic talks.

The first talk was by Kevlin Henney on test-driven development. He is a bit of a guru so we were privileged. Introduction to software process. He says that waterfall works only for projects of 4 days, and the process simply doesn't scale up. In fact, Royce's original 1970 "waterfall" paper was precisely that waterfall doesn't work. Kevlin also says that design is an activity, not a phase, and that design is aways ongoing. A final example doing TDD using assert, to build up a simple most-recently-used class. We all love TDD.

The second talk was by a project (no, correction, a programme) manager. This is how my company manages projects. Page 5. A fricking waterfall. Except that this was Royce's deliberately wrong version of the waterfall with no feedback loops, and no agility. Design was a phase in the waterfall, not an activity. Well never mind. Lots of stuff on how to plan and break down tasks. What the milestones and deliverables are. Time to play bingo.

These are the words and phrases uttered during the project planning talk. I have added a definition to each word for the uninitiated:

activity - what people do when they're not attending meetings.

actuals - evidence that your developers aren't telling you porkies.

approval - when somebody really important nods their head.

at risk - we all know that product managers change their minds at least 10 times before deciding that what they originally said was true. Proceeding under that assumption.

allocation - putting developers on blind-dates with activities. By the time they realise that their activity is a complete dog, it will be too late to back out.

assumption - something that will come and bite you for years to come.

baseline - a line in the sand, that you can erase and redraw when you think nobody's looking. Attempting to change something baselined involves a change-control.

bring the milestone back - someone walked off with the milestone. Catch them, and make them do overtime.

build-cycle - Something that takes 20 manual steps, which takes 4 attempts to get right, whilst most companies press a button and 4 hours later out pops a CD.

buy-in - getting people to agree under false pretences or a big stick.

call-out - what a project manager does when you mention slippage.

change-control - a speedbump on the motorway of agility.

concept-phase - the phase that lasts 50% of the project, because that's the fun bit.

commit - apparently, male developers have a particular problem with this word.

complexity - if your diagram has enough lines on it, maybe you'll keep ahead of the developers??

code-complete - when all is done and dusted, apart from those 10000 defects logged against another project to not upset the stats too much.

complete-date - another fictitious date, in a long line of fictitious dates.

contingency - a concession that project plans are mostly fiction anyway.

critical path - what project managers fantacise about. This is the really important bit that project managers colour in with a red crayon.

dangling task - nobody likes a droopy task.

dashboard - the giant pointer of blame in the sky.

deliverable - at some point, you need to pull one of these out of your butt.

dev-team - the human livestock.

descope - when you realise that your eyes are bigger than your stomach, and you have bitten off more than you can chew.

drum-beat - what you hear whilst the project managers practise their voodoo.

driving - motivating using a large stick.

earliest date - in the starry-eyed concept phase, people romanticise about this date.

estimates - holding a gun so someone's head and asking them to make up a number.

factor it in - something written on a post-it note on the project-manager's monitor.

feature-complete - when it's not ready yet.

firm-up - make less imprecise.

focus - diverting resources from other peoples projects onto your project. Then motivating them with a big stick.

framework - a comfort-blanket for programme managers.

functional test - a game of ping-pong between developers and testers.

Gantt chart - a project manager's autistic little boxes. Giving something a name means it must work, right?

highlight - like Sauron's eye when something slips.

issue - a polite way to say "screw-up".

issue-management - herding cats.

iteration - because developers can't be trusted to think more than 4 weeks in advance.

key milestones - milestones that are less easy to sweep under the rug, but by the magic of shifting, we can anyway.

level resources - working people to the bone.

life-cycle - Plateaus 1-6 in the XwaterfallX project plan.

milestone - something you hide in the closet, that you take out occasionally and laugh about.

mitigation - a carefully constructed NMP field. (NMP = not my problem)

move-in - something your girlfriend wants.

multitask - being able to listen to a talk and play bingo at the same time.

objective - produce as much paper and go to as many meetings as possible. Oh, and deliver on time with quality.

owner - the shareholders of the company. Anybody who thinks they are an asset owner is seriously kidding themselves.

overall risk - multiply all of the risks together, and you get a 50% overrun. Hey the maths works even if the project doesn't.

phase - a magical entity that happens sequentially and concurrently all at the same time.

planning - what project managers love to do almost as much as attending meetings and printing things out.

programme - not to be confused with program. To a project manager, the programme is the deliverable, and the program is a side-effect. To a developer, it is vice-versa.

project-level - something not as important as programme level.

project-plan document - it goes without saying, everything needs a document, and this is the one about the project plan.

project manager - a wannabe programme manager. Someone with a laptop and a PDA, and goes to lots of meetings.

programme manager - where the real power lies. At this point, you get a laptop, a PDA, go to lots of meetings AND you get to boss the project managers around.

project schedule - the good intentions at the start of your project.

quality criteria - a number conveniently chosen to be whatever the quality is on code-complete date.

replan - what happens when fiction meets reality.

rework - in the rush to complete features in isolated projects, nobody had time to spot the fatal flaw.

resource-levelling - working some people to an early grave, whilst others sit around playing darts all day.

resource-manager - someone who makes sure people are looking busy.

risk - something that might become an issue (hey, I didn't go to a risk workshop for nothing!)

risk-register - a list of things that will eventually go wrong, due to Murphy's law.

roll-up - this happens at the end of a phase.

sandbag - I really haven't the foggiest on this one, but it's a verb.

schedule - like a plan, but more official sounding.

shifting - schedule, what schedule? Re-baseline and hope nobody notices. E.g. we shifted Huntsman and it came in on time.

slippage - golden words to a project manager. This will result in a flurry of meetings and paper, which is what project managers love doing the most.

smoke-test - a beehive analogy.

staged development - a process that is so indistinguishable from a waterfall, that people go to great lengths to state that it is not a waterfall. The lady doth protest too much!

system-test - not a unit-test or a feature-test. Monkeys pressing buttons at which point peanuts drop from the feeders.

task - segmenting up what the little people actually do.

team-knowledge - a foreboding of impending doom.

timescale - guess what - Einstein says there is no absolute time. Presumably the project-plan has been travelling at 0.99 times the speed of light relative to the project.

tolerance - what project managers begrudgingly have of developers.

up-front - anything up-front will need to change unrecognisibly, so it's best not to bother.

tracking - if you slip on a project, your project manager will track you to your house and strangle you.

utilise - steal from someone else's project.

visibility - poking your head above the turret. Always a mistake.

And you think techies are bad?!

P.S. This page is a tribute to our programme manager Sarah Walden who in spite of the jargon is fab!

2006-04-23T21:13:00.000+01:00

Wireless routers are ridiculous

Why can't they just bloody work, instead of spending hours running between rooms, resetting devices, hooking cables in, changing region and security settings. Windows XP seems determined to hang whilst acquiring the network address - a known bug in WinXP. The tosser who introduced that bug should get a good kick.

2006-04-23T14:41:00.000+01:00

Opaque library

I've just created a new C++ library called Opaque.

This container can store any C++ datatype in its internal buffer, which can be safely copied and destroyed by code that knows nothing about the type of the stored data.


opaque x = std::string("Hello"), y=x;
x = 2;
assert(x.type() == typeid(int));
std::string &s = y.get<std::string>();
// etc

The container is like Boost.Any, except that it uses an internal buffer to avoid heap allocation. It is similar to Boost.Optional, or Boost.Variant.

Another application is an efficient factory. opaque_ptr is smart "pointer" that can be used to hold derived types. e.g.


class X ...
class Y : public X ...

void factory(opaque_ptr<X> &x)
{
    x = Y();
}

opaque_ptr<X> x;
factory(x);

It was inspired by Bronek Kozicki's work on typeless functor.

2006-04-20T19:29:00.000+01:00

ACCU Conference 2006
Oxford UK

Thursday 20th April

Keynote speech
Helen Sharp (Open) - Software development: a social activity with technical practices

I was pleasantly surprised by this talk, mainly since it's always so refreshing to hear how other people do programming. The main crux of the talk was that programming is fundamentally a social activity, and that aspect is often overlooked. Lots of pictures of programmers working together, and communicating, lots of examples of the different types of interactions that programmers made. Unless you have been living in a box for the past 20 years, this will be nothing new.

What I found surprising is the broad acceptance of agile methods. This is how programmers like to program, unfortunately it is not the way I work at work. Pair programming seemed a lot more common than I have actually seen in practice.

A history of object-orientation was given. A study showed that around 1986, there was a huge explosion of interest and papers in a technology that has been around for 20 years.

The maverick programmer was a very interesting topic. Apparently it is very common for teams to have an "expert", who basically controls the entire team, and likes to be treated like a god. Common traits of these people are to hoard knowledge and rarely document, yet they are still capable of being very productive. Other people dare not do anything for fear of offending of contradicting the maverick. While the quality of their individual work is good, the effect on the team can be disasterous.

Scott Meyers - When C++ Hits the Hardware

I was looking forward to seeing a "Guru" talk, and I was not disappointed. Scott was told to be afraid of the ACCU crowd, and indeed he got more than his fair share of hecklers who really knew embedded programming, better than Scott did. But that didn't matter.

Only two topics were covered - and the bias was definitely towards embedded devices, I was surprised that there was nothing on threading and memory issues, both minefields in the desktop/server.

The first topic was C++ and ROM. The problem is that the standard makes no promises about what ends up in ROM ("ROMable"), versus what must be in RAM. The advantage of ROM is that is is cheaper - there are other advantages too, such as lower initalization costs and being able to share the read-only data segment between processes. A number of examples were given of things that can end up in ROM. Const data, PODs, and stuff with inline constructors and const members. Mutable blows it. It very much depends on the compiler, for example some will ROM structs but not classes. A "trick" is to collate the const PODs into in a struct, and declare that as a static member of a class, which can coerce the compiler. Many compiler-generated data structures can be put in ROM.

The second topic was memory-mapped IO. This is basically volatile memory that doesn't obey the normal rules of RAM. The volatile keyword ensures that the compiler won't optimize away redundand reads or writes. The main example used an enum to reference individual bits, since this is considered more portable that using bit-fields. A wrapper object was created to manipulate the data. Various schemes were presented on how to place the object in memory, including placement-new. Shadow registers were discussed.

What was perhaps the most important principle was how to make the interface to the memory-mapped IO class robust. "Design violations should not compile". The C++ type system was used to wrap addresses, thereby adding a safety check. The destructor was made private. Another important realisation was made, that inline keyword is not about improving efficiency (although it does), but about improving abstraction. Programmers won't be deterred by a performance penalty of adding abstraction.

David Burggraff (Microsoft) - Win32/WinFX integration

This was in part a call for everyone to use Windows Vista and CLR. I has to sit through a little bit of marketing, and then there was a whistlestop tour of programming in the CLR. Many C++ extensions where shown, and how to combine native and managed code. Normal C++ can be compiled under CLR and work every time, and then it can interoperate with managed languages and extensions. Very nice indeed.

WinFX is the official name for "Avalon". It is a new UI library which can be specified either in code or in XML. The XML is capable of expressing complex behaviours. Tools are capable of designing rich GUIs without code, and can generate the XML. Some very nice effects are supported, such as layering and alpha-blending. GUIs produced in WinFX are likely to be much flashier, and easier to write.

WinFX interoperates with Win32. The main part of the talk was to show how easily and seamlessly it was possible to migrate, and mix Win32 code with WinFX and the CLR. As an example, they rewrote part of Powerpoint using WinFX, and also the Hearts server and client. The line-count was lowered significantly for Hearts, while improving the visual appearance.

Bronek Kozicki - Typeless functor
The main objective with this is to create a class that can call a function with data, even though we don't know what the type of the function or argument is. This sounds pretty useful, however no really good examples were given. Scopeguard was suggested, though I was thinking that event handling (for example as part of a GUI) would be a more realistic example. The other goal was cheapness - otherwise why not just use a virtual functor.

Various examples were built up, and there was a lot of staring at code, perhaps too much. The main principle is to create a static templated function, which we can then take the address of. We call the static function with data that was packed into a small block of memory allocated inside the typeless functor object. The major problem with this approach is that it only works for PODs, which in my opinion is too restrictive. But unless you expose types, there is only so much you can do.

The main power with the typeless functors was the ability to copy data about, and to access the argument in a typed way by comparing the address of the function, which is a cheap way of doing RTTI. The number of arguments can be mixed, currently 0 or 1.

The main drawback with the approach was that it falls in between tr1::function and boost::any. It only works for PODs, which is hardly modern C++. The scopeguard example was particularly uncompelling since normal scopeguard implementations just use a reference and can work with any data types whatsoever with no performance penalty. However the technique of using a reference only works for local scope - you can't copy opaque data.

Some good comments came out, for example why not initialise the functor with a "null" function, or a policy-based null.

Agile with Offshoring - Panel with Jutta Eckstein and Nico Josuttis

This was completely unexpected, since the format was a discussion with 5 people in the middle of the room, and people could sit in the main discussion chairs at any time, with the only rule that if one person enters, another must leave. This was quite a fun way of doing things. However since I have no experience of offshoring, I did not enter the discussion.

The discussion was to try to establish best practises, and understanding, of the combination of two extremely widespread phenomena (at time of writing) - Agile development and Offshoring.

The main issue was that offshoring has huge communication overheads. Thus, although there may be gains in terms of reduced salaries, the teams will work much less effectively due to communication problems. Other problems cited include hugh staff turnovers in offshore companies, and that key developers in the main company spend a lot of time training people up only for them to leave.

Such difficulties had lead some companies to abandon offshoring completely, once the math had been done.

It was questioned whether offshoring is at all compatible with agile development. Agile relies on enhanced communication, something offshoring cannot deliver. How can one pair with somebody 6000 miles away? The main issue is trust, since people tend not to trust people they have never met. Offshoring is a management decision which developers rarely support, while agile is a development decision that managers often don't support without persuasion.

Agile also involves developers meeting customers, which clearly is not achieved. If agile cannot work as such distances, should projects be split such that entire projects are taken offshore?

A large challenge is cultural differences - in some cultures people always claim to understand something, and say they are able to deliver, even though they cannot.

A point was made that the audience was very biassed - none of us has been developers in developing counties. Offshore developers feel very used and resentful of their oppressive employers, and it is not surprising since they clearly are being treated as second class. Overseas developers do not want to be programmers, they want to quickly progress to management, and into better paid jobs. As soon as they increase their skills, they are out. Programming is not seen as a career.

Working relationships are very important, and very difficult to foster at such distance. Nevertheless it is important to try to make friends.

There is a conundrum. Open source software is extremely effective, extremely global, and extremely agile. Perhaps the main difference is that open-source programmers treat each other as equals.

There was no real conclusion, other than that offshoring hinders agility.

2006-04-01T11:59:00.000+01:00

Gotta get me one of these.

First post

2006-03-15T08:36:00.000Z

Test