When Someone Leaves

It’s a fact of life that people will quit your organization.  If you’re doing your job as a manager, you should have expected this; few people leave on a whim, and the warning signs stretch from complaints to repeated dental appointments with no apparent improvement in the smile.  Still it often comes as something of a shock when the day finally comes.
The first thing to remember is that it is almost always positive for both the employee and the organization.  The employee is leaving for something that is surely perceived to be an improved personal opportunity.  The organization, no matter how key the individual might be, will find a way to recover and will be stronger because of it.  There will be a short period of adjustment, and then you’ll adapt.

I once worked for a company that asked as soon as the letter came, “Can we save them?”  Sometimes we could, but inevitably, once someone is looking for a new job, they have effectively already left.  Whenever we saved them, they continued on at reduced performance for a few months and eventually left anyway.

Incidentally, having seen the other side of the same coin, the reverse is true.  A company that promises to reform itself to keep you probably won’t and you’ll be looking for work again in a few months.  And extra cash only makes you feel better about the personal sacrifices you’re making to come into work for a little while, and then the underlying reasons come back to the fore.  So, if a company is trying to convince you to stay, then remember that it’s only going to be for a few months anyway.
So, you’re going to lose staff, and while I suppose you could have a current succession plan in place for everyone who you consider a retention risk, you probably don’t and in the end, you only have two weeks to deal with the disruption.  At one place I worked, we developed a formal process for dealing with this.  It wasn’t that it happened frequently, but rather that it happened infrequently, and bungling an exit was expensive.  We wrote it down because when you lose someone you sometimes feel like panicking, and having a process quells panic.

The first step is to acknowledge to yourself that the person is leaving.  As I say, there is nothing that you can do to avoid this, although you can postpone it.  You should first congratulate them on either finding a new opportunity.

It is reasonable to inquire where they’re going, as I suppose this could impact how you treat them for their notice period.  Often salespeople who are going to a competitor, for example, get walked out the door in a vain attempt to reduce the damage.  However, realistically, they are taking their customer list with them, and they already have it filed somewhere.

You should also look at this initial meeting as an opportunity to learn.  Is the person leaving because of you or the organization?  How can you improve so that others don’t leave for the same reason?

Once you’ve satisfied yourself with the conversation, it’s time to start getting the word out and planning.   You should talk to the employee to ensure you know everything they do; especially with long-standing employees, you may not know it all.

You need to tell all the internal people who will be directly impacted by the change, find out what their view of the impact will be, and work with them to come up with a near-term and medium-term plan to manage that impact.  Hiring falls in the medium term.  Reasonable near-term plans are hand-off to existing staff, documentation and deferral of responsibilities or termination of responsibilities (you can stop doing things).

By the end of that first week of work, the plan should be known to everyone internal, and you should be starting to communicate it externally.  Your customers and suppliers need to know there is a plan and that the situation is under control.

The second week should be completely about implementing the plan.  I wouldn’t expect the exiting employee to do much more than to think about their new opportunity.  If there is hand-off to be done, they should be doing that early in the week, and overseeing the newly responsible person as they do it by mid-week.

At the end of the second week, you should have a leaving party.  Everyone needs an opportunity to say good-bye, and this party is more for the folks who are staying than for the one who is leaving.

Availability: it’s expensive

I was jawing today with a developer who wanted to build something a little more robust than we needed it. He didn’t do it, but he thought it would be interesting and fun (the root of another blog post one day, perhaps).

The thing is, generally cost is proportional to something like the exponent of the uptime requirement. This is why uptime is so often expressed in terms of percentage: if 9% uptime costs 1 dollar (say), then 99% costs 10 dollars, 99.9 costs 100 dollars, 99.99 costs 1000 and 99.999 costs $10,000. Now think of what an underpaid junior developer can develop in under 6 minutes, because that’s what you can build robust enough to stay up for all but five minutes per year for $10,000.

Don’t believe me? I bet your junior developer could develop something that continually writes incremental integers to the screen in six minutes. Now, how would you make that survive power failures, screen failures, how about hot-replacement of parts? Yeah, now you’re talking about $10,000.

A couple of questions to consider in acquisition

When your CEO goes to buy another company, the chances are they’re going to ask you, their trusted technical advisor, to have a look and decide if their technology is worth acquiring. Now, I’ve never heard of an acquisition stopping at this point, but I suppose it could affect the offering price. Here are some questions that are relevant:

1. How is the company protecting their intellectual property? What patents does the company hold? What are the relevant patents in the space, and why does this company not infringe on those patents?
2. How much can the company and their systems scale? Can they readily accommodate the increased demands of an amalgamated company? What are their plans for scaling beyond the handful of customers they have today?  Has this scaling been proven?
3. What is the state of the company’s equipment?  Is it leased or owned, how much life is left in it?
4. What are the development processes that are currently in place?

Any company should be able to provide you with a number of architectural diagrams.  I would look for logical and deployment views to get you started.  There should also be a good entity relationship diagram for each database.

Colour – The CTO Weighs In

I guess colour is a key aspect of a brand. All the companies I’ve worked for have spent huge sums identifying the exact colours that they will use to represent themselves. Then the marketing department hires a small team of brown-shirts to police that palette.

So, you’d think they would have really tight control over what exactly that colour is.

Unfortunately, colours are decided by marketing people, usually under extreme pressure to complete the project and they don’t think ahead to the technical requirements of the job. And the one technical requirement that we have of colour is to know exactly how to reproduce it in a variety of contexts.

Now, I’ve just had an interesting experience reviewing our brand book, because we wanted to get our particular colour right on an online form. Sadly the brand book contained only CMYK and Pantone colours — useless online — which lead me to a colour converter, and ultimately to the Pantone website. If you think for five minutes, you can use the Pantone website to convert a Pantone colour to their suggested RGB value. The very strange thing is that none of these colours matched: they didn’t match by value and they didn’t match by looking. So, we were no further ahead, apart from an interesting dicussion with the local colour nazi, who gave us the colour he uses — another county heard from.

So, if I’m ever working with a company that is redoing its graphic standards, and I have a chance to affect the graphic standards, I am going to try my best to withhold judgment about the chosen colour: there will certainly be enough executives squabbling over that. However, I will insist on the following:

1. Do not accept only print-centric colour spaces! The agency owns a copy of the Pantone Color Bridge, and should at least give you the Pantone RGB, HSV and other versions of the colours .

2. Test the colour specifications suggested, rather than accepting that they look like the graphic standard. Bear in mind, they will appear different on different types of stock, under different lighting, with different monitors. But you should be able to get something that looks reasonably close.

Budgeting in MS Project

Until now, whenever I have wanted to build a budget, I have always used Excel, as I’m pretty sure everyone who doesn’t use paper does as well.  Lately, I have been revising my budget for the fiscal year, which consists of many many projects and opportunities.

It’s a lot easier for me to try to estimate project costs using MS Project.  I can think about a single project, the tasks that are involved, who would have to do them, and the dependencies between them.  Furthermore, MS Project makes it relatively easy to add up the number of individuals of a certain type you’ll need.  So that’s how I started out, fully expecting that I would take the projects and their costs and paste them into my spreadsheet.

However, when I paste it into Excel, I lose all the dependencies between projects: it’s hard to show that three projects share a common pre-requisite.  Not only that, but if I think further about a particular project, refining the numbers, I would then have to go back to Excel and update it there (hmm, I wonder if a .mpp can be a data source for a .xls?).

So, I decided to stay in Project.  I was pleasantly surprised to find that I could change all my resource hourly costs to negative numbers, and Project behaved the way I expected.  Then I started thinking about benefits.  I’m entering the benefits as positive numbers under the same project.  Projects that wind up positive should get the green light.   I still have a slight difficulty with those prerequisites because they never get a positive number; I suppose I could apportion some of the dependents’ revenue numbers to the prerequisite to get them to happen.

The one benefit of a spreadsheet-based approach is that I can use formulas to figure out other costs.  For example, every developer comes with training costs, workstations and doughnuts, and I would really like to show those costs separately rather than burying them in the loaded cost for a developer.  So far I’ve not figured out a way to make MS Project do this for me.  If I figure out how to make it a data source for Excel, though, I’m off to the races!

One Big Message?

This is the scenario: periodically, one component is going to look for objects that satisfy some criteria and tell the others. For example, perhaps it is the accounts whose billing anniversary is today. A bunch of other components are interested in these accounts, and so we’re going to send a message out that they can subscribe to and be notified of billing anniversaries. Clearly the initiating component is going to do a single query and get back a big list of accounts; should it send out a single big message, or many small ones?

Ordinarily, when one component is talking to another, I like to see as much go into each message as possible. This was a lesson we learned back in the days of CORBA (which I realize may not be completely over everywhere) when, based on some particularly optimistic advice from authors who had apparently never actually built more than sample code, everyone I worked with was composing interfaces for inter-process communication that exposed miriad small methods. The key to killing performance of distributed systems, it turns out, is to make communication synchronous and chatty so that the communication overhead dominates the payload. Maybe this is what killed CORBA for so many people; I have no doubt their early experiences with performance sewed some initial seeds of doubt.

However, in this case, we don’t have the same scenario. First of all, we’re talking about asynchronous communication. So, while we would add communication overhead by going with multiple small messages, it’s overhead that will only affect total processing resources, and not latency of individual requests. On the other hand, there is quite a bit to be gained from using multiple small messages –

• we can route and filter the individual messages based on their contents.
• we can scale the message processing by “simply” adding more sinks.
• we can be much less clever about interrupted processing: the sink consumes each message in a transaction, and so, a failed transaction will be restarted automatically (perhaps by another recipient)
• the constant-size messages mean that the sink does not have to scale. So, if we have a simple in-memory reader for the message that works for 20 accounts today, the same reader will work tomorrow when we have 20k accounts.

It’s a small question in the grand scheme of enterprise architecture, but all these small things add up.

Perhaps the next question is: how small is too small?

Scripts and Programs

What’s the difference between a script and a program?

Most people to whom I ask this question jump at the idea that a script is interpreted, and indeed, the Wikipedia page on scripting languages currently makes that distinction.  However, there are lots of interpreted programming languages — Basic, Prolog and Smalltalk all leap to mind — so that can’t be it.

So then, most people tend to say something to the effect that scripting isn’t serious, while programming is.  Well, that might be true, but it also has huge implications!  If scripting isn’t serious, then is there any need to apply proper software development practices to scripts?  Do you need to keep scripts under source control?  Do they need requirements?  Do you need to test them thoroughly?  What about documentation?

The assumption that scripts are not serious has serious implications to an organization’s stability.  Organizations that don’t value scripts wind up with a host of arcane code snippets sitting on servers, known only to a handful of sysadmins who have composed them and shared them with others.  When those sysadmins leave, their tools whither in lost directories and the organization breaks.

My own definition is this: a script is a sequence of instructions that is only intended to run once without modification.  Any script that you plan to use more than once is a program and deserves to be treated and cared for with the appropriate respect.

This has the interesting side effect that you can write programs in languages that are called “scripting languages,” and may, like JavaScript, even have “script” in their names.  Perhaps I am swimming upstream, but I would say that the standard definition is useless and indeed dangerous.

So don’t tell me, “there’s just a little script that runs nightly and downloads the billing information,” when what you mean is “there’s a critical csh program…”  Such scripts deserve all our respect!

Blogged with Flock

Purchase is just a special case of Exchange

When you forget something that you learned before, perhaps it’s time to write it down.  So here goes.

It turns out that what most people think of as e-Commerce, and in fact, any kind of commerce, is just the very tip of the iceberg.  What is below the surface, behind shopping carts and packing and shipping is a huge ugly monster – the exchange process.

An exchange is a process where a customer purchases some items, returns some of them and receives replacements for some of the returned items.  So, you see, both Return and Purchase are special cases of this flow. 

The first time I came to realize this, we were building a very nice e-store.  Unfortunately, no-one had thought about returns or exchanges at all.  Indeed, it was unclear whose responsibility they were!  So, the store kept getting more and more elaborate, and no one thought much about returns until we came to writing the terms and conditions (how this happened is a story for another day).  Needless to say, that was much much much too late to make a really snazzy experience for the customer or indeed for the poor service agent.

What we should have done is started thinking about exchanges up front.  How would inventory move from the warehouse to the customer and back again?  How would the money work, and what about the taxes? 

Now, I’m working on another offering, and realized after a two-hour session on the purchase, provisioning and billing of a service, we hadn’t thought yet about the exchange side.  Fortunately, it happened before we got too far down the road, but it would have been so much more efficient to have come up with it up front.

If you concentrate on the exchange process up front, you may be able to build hooks into the purchase process or even the product design to make the exchange easier (or indeed possible).  The simplest example is a shipping label that goes into the box to enable the customer to return items — this can be barcoded to identify the items and original shipment.

So next time, don’t have a meeting to discuss the purchase process, but to discuss the exchange process.  You can touch on the purchase if you want, but it’s the exchange where the real issues show up.

Blogged with Flock

A common trap

Maybe I’ll make this into an interview question one day. Yesterday I was trolling through some code for a little script that ETLs from one database to another. It looked a bit like this:

void quit() {
db1.rollback(); db2.rollback();
db1.disconnect(); db2.disconnect();
exit;
}
void main() {
if (!db1.connect()) exit;
if (!db2.connect()) exit;
writeStuff(db2,getStuff(db1));
if !(db1.commit()) quit();
if !(db2.commit()) quit();
db1.disconnect(); db2.disconnect();
}

Now, I’ve simplified tremendously here, and there was actually some error handling in getStuff and writeStuff, which made the code look somewhat robust, but what about those two commits? Now, the interesting thing about this was not so much the code, which is wrong, but but rather that I was talking to a colleague who I regard as a highly talented and extremely productive developer, and he didn’t see anything wrong with it. It all makes me wonder how much of the world’s code is rife with similar errors.
So, if you’re ever in an interview with me, get ready for this question.

TortoiseSVN SSH and Certificates

Right, so, there is an excellent post here: http://tortoisesvn.net/?q=node/5 that describes how to get Tortoise Subversion to authenticate with a certificate.

The problem I have with many how-to articles is that there is not enough room among all the steps to explain why the magic works. I’ve written how-to articles as well, and I know that this is an easy trap; it is, after all, time consuming to enumerate all those steps. However, especially with software systems, where there is often magic involved, it’s important to explain the trick so someone can trouble-shoot the inevitable problems.

In this case, on the client side, there is some magic around how Tortoise figures out where your certificate is. It turns out that Tortoise is looking for a registry entry /SimonTatham/PuTTY/Sessions/sessionname/PublicKeyFile, where sessionname is the host name in the repository url. Putty creates one of these entries for each session that you save, which for me, is for each server that I try to connect to, and so the distinction is a little bit subtle. Tortoise, is trying to find a repository at svn+ssh://username@sessionname/repository.

So now, if you are having trouble with TortoiseSVN asking for a password over and over again, make sure you’re using the name of the PuTTY session, and not, say, the name of the server.