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!

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.

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.

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.

Gotta get me one of these.