The Mystery of the Disappearing Bccs

I’m supposed to be an email expert, so you can imagine that I was pretty frustrated not being able to understand why Bcc recipients were disappearing from my sent emails.

Let’s set the scene: I am nursing my old Windows Vista desktop through the end of its life, and setting up shop on a new laptop. I use Office 2007 as my ‘productivity’ tools, and this includes Outlook: I connect to my external email provider using IMAP, and manage all my emails that way. So I installed Office on my laptop, and configured Outlook to connect to my email account.

The problem: however, the emails in my Sent Items on the laptop don’t quite look like the same emails in my Sent Items on the desktop. More specifically, the desktop emails, when opened (not using the preview pane, which never shows Bcc recipients), properly reflect any Bcc recipients I had set, whereas the laptop emails don’t. Interestingly, the laptop emails contain populated Internet headers (and I can see the Bcc recipients listed in there), while the desktop emails don’t – this will become important later.

Quite a few of the emails I send contain Bcc recipients; for instance my Neighbourhood Watch messages do, and I often use the “Resend This Message” on these to avoid having to re-type a fairly long list of Bccs every time.

So it was important that I figured out what was wrong. Was it a different configuration of Outlook? Nope. Was is a different configuration of the email account? Not that I could see. Was it a different set of Add-Ins, with one of them (missing on the laptop) somehow properly populating the Bcc field from the Internet headers from the emails on the server? No, but these internet headers were nagging me.

One simple test provided an important clue: sending a Bcc mail from my laptop. Of course, it also appeared in the Sent Items in Outlook on my desktop, but there, it was lacking the Bcc recipient (and had Internet headers), whereas on the laptop I could see the email with its Bcc recipient intact (and no Internet headers) – the situation was reversed between the laptop and the desktop.

Ah, now I understood! The mystery was pretty simple after all. You see, Outlook stores emails etc. locally in a PST file (Personal Folders File). When you set up an email account in Outlook, you’ll have a PST file (or a PSO file for Exchange emails) on your hard disk mirroring the content of your account as it is on the email server (with Exchange accounts, you can turn that off, but that’s a different matter). This way, you can work offline, and not need to be connected to access your mailbox. Of course, initially the PST file is empty, and right after you set up a new email account in Outlook, it will spend a little time downloading the emails (at least all the ‘headers’ – the actual contents get downloaded on ‘first-read’) from the email server and copy them into the local PST file…

Also, when you compose and send an email, it’s usual to save a copy in a “Sent” folder (which may go by slightly different names). In my case, I had selected to have all sent emails copied to the Sent Items folder in my email account – the default is to save a copy in the Sent Items folder in the local-only “Outlook Personal Folders” (also a PST file, but a different one). This way, my sent emails were always saved in the email account, and accessible from anywhere. At the same time, a copy of these emails was obviously kept in my local PST file.

But that’s where the difference, and the lack of Internet headers, explained what was happening:

When I send an email from my desktop, Outlook at some point proceeds with the sending itself (talking SMTP to the email server), and then copies the email to the Sent Items folder in the PST file (it’s more a move from the Outbox folder, but that’s a technicality). That copy of the email is also sent to the email server (either through synchronisation of the PST file’s content via IMAP, or actively by Outlook sending the individual email via IMAP to the email server, or through an accessory command during the SMTP process – it doesn’t matter here). The important bit is that what’s in the PST file is a copy of the email in Outlook’s internal format, an original MAPI message – there are no Internet headers (the email never passed through the Internet). What gets stored on the email server however is an Internet format email – with Internet headers.

In turn, on the laptop, Outlook spots that a new email has appeared in the Sent Items folder on the server, and it pulls it in to the local PST file for the email account. While doing this and converting it to a MAPI message, it does not convert faithfully and fully. The Internet headers are preserved, but in particular the Bcc recipients listed in there are not transferred to the list of recipients in the Outlook format email (MAPI) in the PST file.

So there you have it, in short:

Send → copy in Sent Items in PST file (original MAPI, with Bcc recipients)
→ copy sent to Sent Items in email account (Internet format)

Separate synchronisation, email in Sent Items in email account
→ pull copy to Sent Items in PST file (Internet format→MAPI, no Bcc recipients)

In other words, only a copy of the sent email to the local PST file for the mailbox by the sending Outlook will have Bcc recipients preserved. If Outlook didn’t send the email, or not in this ‘lifetime’ (PST file from when the account was set up), it won’t have Bcc recipients.

Additional info:

Why doesn’t the sending Outlook later pull in the sent email from the email server, during a re-sync for instance? Well, the email is already there in the PST file (each email has a unique ID), so there is no point in pulling it from the email server to replace what’s already in the PST file. Zap your PST file though, and Outlook will pull everything back in, and convert to MAPI format, and you’ll magically now have Internet headers and no Bcc recipients on all these emails.

Is there other data that doesn’t make it from the email server? Probably, but I didn’t look into it.

Does this happen with all versions of Outlook? I don’t know. It definitively works that way with Outlook 2007, but Microsoft may have changed that in later versions.

Did I find out exactly how the PST file gets synchronised with the email server? No. It wasn’t necessary to find out.

So I’ve got this bunch of emails with Bccs I want to preserve to use with Outlook. What do I do? Come back later, I might have a solution. I’m going to try to ‘transplant’ the PST file from my desktop to the laptop… That didn’t work; don’t try it.

Posted in Email musing | Leave a comment

Experience is not competence

Competence is being able to do something well.

Experience is the accumulation of knowledge and know-how that, if used well, can enhance your competence.

But while experience can enhance your competence, the two are not rigidly linked, and experience and competence do not correlate well. You can keep accumulating experience—it’s like entropy—but you can’t “accumulate” competence.

Experience is not competence, and to see a real-world example of that, you just have to venture out on the road and witness the antics of drivers who supposedly have passed tests to hold a driving licence, and for most of them, have accumulated experience, yet are seemingly incapable of mastering the simple art of signalling (or even apparently understanding what it’s for).

Currently on the hunt for my next interesting job, I’m faced with the understandable approach of recruiters who look for specific skills and experience, but have a much harder job with competence, which is more difficult to assess, although ultimately more valuable. Just like experience doesn’t imply competence, a lack of experience doesn’t imply incompetence – just a lack of knowledge and, er, experience.

Posted in Thoughts and opinions | Leave a comment

Brexit—what have they done?

Note the third-person form of this post’s title. That’s because I didn’t vote in the recent referendum. That’s not because I couldn’t have voted, if I had truly wanted to, but to do this I would have needed to become a British citizen first, and this takes some advance planning. I never, truly, deeply, felt that I needed to become British officially. I am British in all but name—I’ve lived and worked here for nearly 30 years; this is my home—but I am also European because I’m French, and with British people being also European (still so, for the time being), I felt that we all belonged in the same place.

Should I have been able to vote? That’s a bit of a moot point now, but it’s arguable that as a long-term permanent resident (and productive member of society), I should have been able to. I have as much at stake as any other resident, citizen or not. I have at least as much at stake than citizens who are not resident, yet they could vote and I couldn’t.

To people who might object by saying that it was a British matter, concerning the UK, and that only British citizens should vote, I will say that I cannot entirely disagree. Yet, how long do you have to live somewhere to be able to participate? With my track record, shouldn’t I have been given the right to vote too? All the UK citizens who have made their home somewhere else in the world were entitled to vote (ok, technically, only if they had been away less than 15 years), even though they might never come back. Sure, they may well be directly affected, for instance because they are drawing a pension from the UK, but conversely they might not be affected whatsoever, but could vote, yet here I am being directly affected, but couldn’t vote.

I suppose I can only blame myself: if I had really wanted to vote, I should have become a British citizen a long time ago. Living here and being European turned out not to be enough after all.

Posted in Uncategorized | Leave a comment

Is it Christmas already? Déjà Noël ?

The saying is that “time flies when you’re having fun”, yet it is known that time perception slows as you’re experiencing new things.

That seems a bit like a contradiction: time is passing slowly, yet it feels like no time has passed when it’s over?

Well, it certainly feels like that to me. A few days ago, I celebrated (quietly) my first anniversary working for Dell Software. It has been a year of discoveries, new colleagues, new things to work on, and some lulls (as it sometimes happens). It certainly didn’t feel like time was rushing by. Yet here we are, and last year’s Christmas feels like, well, a few days ago…

My theory (although I wouldn’t claim to have invented it) is that your personal sense of elapsed time is affected by how long you’ve already lived. When I was little, life seemed to take forever. Even when I was 18, five years of engineering school to get my first degree seemed like a very long time. Now that I am 50, one more year is only an extra 1/50th, then 1/51th… When you’re 10, the next year is a whole 10% of your life all over again—whoa 🙂

Oh well, Merry Christmas everyone, again 😉

And a Happy New Year 2015, of course.


Le dicton est que “le temps file quand on s’amuse”, bien qu’il soit connu que la perception du temps est ralentie quand nous faisons l’experience de choses nouvelles.

Cela semble contradictoire: le temps passe lentement, mais il semble que ça n’a duré qu’un instant quand c’est fini?

En tout cas, c’est l’impression que j’ai. Il y a quelques jours, j’ai fêté mon premier anniversaire chez Dell Software. Cela a été une année de découvertes, nouveaux collègues, nouvelles choses sur quoi travailler, et quelques périodes creuses (comme ça arrive). Il ne m’a pas semblé que le temps passait vite. Et pourtant, il me semble que le Noël de l’année dernière était il n’y a que quelques jours…

Ma théorie (que je ne prétendrais pas avoir inventé) est que le sens personnel du temps écoulé est proportionnel à l’âge. Quand j’étais petit, le temps ne semblait jamais finir. Même à 18 ans, cinq ans d’école d’ingénieur me semblait très long. Maintenant que j’ai 50 ans, une année de plus n’est seulement qu’un 50ème de ma vie, puis 1/51ème… Quand vous avez 10 ans, l’année qui suit, c’est un plein dixième de votre existence complète à vivre à nouveau—m’enfin!

Allez, Joyeux Noël à tous, une fois de plus 😉

Ha, et Bonne Année 2015, bien sûr.

Posted in Everything else | Tagged , | Leave a comment

The benefits of continuous micro-fixing

In software engineering, “micro-fixes” are these small fixes that you make to the code of a software product. Like the fixes of defects of all types and sizes, they are synergistic: the overall improvement is always greater than the sum of the individual ones. Also, continuous micro-fixing decreases the future cost of maintenance and support, and this in turn increases the amount of resources that would otherwise become unavailable. Ignoring small defects or starving them of resources is a false economy, because their impact on the product, and therefore on the customers, is often disproportional; and their eventual fixing, necessary or simply desired, will cost much more and deplete the availability of resources for other work like the development of new features. Continuous micro-fixing improves quality, decreases costs, and frees up resources.

An example: a few years ago, I happened to find a bug in a routine that had been recently modified as part of bigger defect being worked on. In effect, this was a bug in a fix. The problem code was just a few lines long. The bug was not currently provoked, but a change in the routine’s use would result in incorrect data, with potential bad consequences at customers. Circumstances meant that I had to raise a new bug report or the information would have been lost, but I also notified the developer who had modified the routine, pointing out the problem, and stressing the importance, in my opinion, of an immediate fix—at that point it would have taken no more than an hour to fix and test. Instead, he ignored the bug on the ground that it wasn’t ‘live’ and wasn’t affecting a customer… A year and a half later, a customer’s problem was eventually diagnosed as being caused exactly by the bug I had reported. Besides the intangible of an irritated customer, this had so far cost 25 to 40 times more (leadtime was much greater) just to get back to the bug report than fixing the bug in the first place would have been… and we still had to fix it and deploy the fix.

In my reasonably long career so far, I have often encountered similar scenarios. Usually there are plausible excuses to avoid doing the work, like lack of resources or time pressures. But these are actually fallacies: studies have clearly demonstrated that the earlier you fix a defect, the dramatically less it costs. In Code Complete [ref1], the author writes:

[…] focusing on correcting defects earlier rather than later […] can cut development costs and schedules by factors of two or more (McConnell 2004).

If you reverse the findings, the conclusion would be that if you don’t take the time and make the effort to fix defects then you will continuously lose time and resources as you move forward. Time spent fixing is always an investment that pays off many times over—and this includes micro-fixing.

So, what are micro-fixes?

Let’s have a look first at what a micro-fix is not for:

  • A defect whose cause is unknown and takes time to find.
  • A defect found but whose fixing is complex or delicate or risky.
  • Major problems found during a code review.
  • The review and copy-editing of a whole set of UI message strings.
  • A single defect, which when examined, turns out to be a “class” defect (many instances affected).
  • Medium to large refactoring which would take days to implement correctly.

On the other hand, these are good candidates for micro-fixes:

  • A bad message string (typos, grammar, ambiguity, terminology, etc.).
  • A compilation warning.
  • A missing boundary check.
  • A buffer under/overrun.
  • A localised resource leak.
  • The undefined behaviour (or misbehaviour) of an edge condition.
  • An incorrect test condition.
  • An incorrectly nested set of conditional statements.
  • A wrong calculation, pointer arithmetics, array index access, etc.
  • Minor refactoring.
  • Many language or technology-specific small problems, e.g. COM incorrect AddRef‘ing and Release‘ing of objects.

I would also include in micro-fixes these small changes which are not fixes as such (there is no actual or potential operational defect), but which work to prevent problems from appearing by improving readability and clarity. For example:

  • Inserting or fixing comments.
  • Documenting a function’s parameters.
  • Reformatting code.
  • Re-arranging a complex conditional sequence.
  • Giving a symbol a better name.

The criteria are that…

  • … the defect must be small (although its potential impact may be large), e.g. a few lines of code;
  • … the overall time necessary to fix it and test the fix should be short, e.g. from a few minutes, to a couple of hours maximum for the largest micro-fixes;
  • … the defect, the fix, and the results, are entirely understood.

If a defect looks like it is convoluted, or the effect of a fix is not entirely determined, or there is a risk of regression, or simply you don’t entirely understand the defect, then it’s better to raise a bug report and let the matter be handled that way—all genuine bug reports are important; it’s only their priority which may need to be adjusted.

Should you raise a bug report for a micro-fix?

Typically, no (but see above), as it is often the case that the life-cycle of an official defect (reporting, triage, allocation, implementation, testing (which may be impossible or meaningless from QA’s point of view)) will consume more resources than fixing the defect itself would (many times over in some cases); so it’s not worthwhile in these cases.

Also, for some types of defect, reporting them could be deemed facetious—and arguably this would be reasonable.

If the defect is reported, another risk is that it will never get worked on: its small size, mistaken for low importance, means that it is forever relegated to the bottom of the pile, with more “important” defects continuously prioritised ahead of it—we have “resources starvation“. Too many such reported defects, or too many more “serious” defects, only aggravate the situation. There are a few potential solutions to that problem, and they all involve shuffling priorities to break the “starvation” process.

(Worthy of note is that resources starvation also happens for defects bigger than those of micro-fixes’ yet still comparatively small. The solutions are the same—but I digress.)

Traceability

So, typically you would not raise a bug report for a micro-fix, but you still need traceability:

  • If you are working on an existing bug, then micro-changes can usually go under its umbrella as long as there is some subject matter connection, even when the defect is in a different area. This should be noted in the bug’s log, and the version control system will keep the record of changes implemented.
  • If you are working on a new feature or some improvement task, then there will usually be a process in place to record progress—use it.
  • If the micro-fix is completely outside the area of work you’re currently involved in, then it is usually possible to tag a change with “maintenance” in the version control system.

A rule of thumb is that any change to the deliverables of the product (e.g. executable code) must be traceable.
For any other change (e.g. internal code documentation), use your judgment, but err on the side of caution.

Conclusion

The impact of micro-fixing ranges from small (e.g. a typo which doesn’t change a message’s meaning) to disproportionally big (e.g. a very small defect with a very big effect), but cumulatively they always make a big difference. Unfortunately, tackling the defects is often dismissed because of a perceived lack of resources, or because the benefit is not immediate (fixing a reported problem).

Of course, micro-fixing contributes to ‘total quality’, which is an asymptotic goal in that it can never be reached but should always be aimed for.

But more prosaically, the benefits of continuous micro-fixing include sustained improvement, easier maintenance, the avoidance of future problems, maintaining or increasing the availability of development resources in the future, and even the serendipitious fixing of currently reported defects—all of which is often underrated.

Most developers do some micro-fixing as part or their work, but this can be implicitly or explicitly discouraged. Instead, to reap the benefits, this should be actively encouraged from higher up. For instance, suggest that developers spend up to 10% of their regular time on that—time easily recouped, with interest, later on.

[Update 2014-11-26] I am re-reading Code Complete by Steve McConnell [ref1]. Steve points out that the topic of code construction has been neglected (to the detriment of software development in general), and I found the following small section in the preface rather resonating with my point of view. The two highlightings are mine, drawing attention to these key sentences in their full context. (I hope that I didn’t require permission for this longer quote.):

Construction Is Important

Another reason [see book for details] construction has been neglected by researchers and writers is the mistaken idea that, compared to other software-development activities, construction is a relatively mechanical process that presents little opportunity for improvements. Nothing could be further from the truth.

Code construction typically makes up about 65 percent of the effort on small projects and 50 percent on medium projects. Construction accounts for about 75 percent of the errors on small projects and 50 to 75 percent on medium and large projects. Any activity that accounts for 50 to 75 percent of the errors presents a clear opportunity for improvements.

Some commentators have pointed out that although construction errors account for a high percentage of total errors, construction errors tend to be less expensive to fix than those caused by requirements and architecture, the suggestion being that they are therefore less important. The claim that construction errors cost less to fix is true but misleading because the cost of not fixing them can be incredibly high. Researchers have found that small-scale coding errors account for some of the most expensive software errors of all time, with costs running into hundreds of millions of dollars (Weinberg 1983, SEN 1990). An inexpensive cost to fix obviously doesn’t imply that fixing them should be a low priority.

The irony of the shift in focus away from construction is that construction is the only activity that’s guaranteed to be done. Requirements can be assumed rather than developed; architecture can be shortchanged rather than designed; and testing can be abbreviated or skipped rather than fully planned and executed. But if there’s going to be a program, there has to be construction, and that makes construction a uniquely fruitful area in which to improve development practices.

[ref1] Steve McConnell. 2004. Code Complete – Second edition. Microsoft Press. ISBN 0-7356-1967-0.

Posted in Software engineering, Thoughts and opinions | Tagged , , | Leave a comment

It’s not its

I am constantly saddened by the poor standards of writing in general.

On the one hand, I know that this is nothing new, as there will always be people who can’t write correctly, lots of them, to varying degrees. That is not a judgment; it is just a fact. Is it getting worse? I don’t know. With the online world we live in today, it is far more visible – but not necessarily worse – than it would have been before. My hope is that all this writing activity might, just might, over time, improve standards.

On the other hand, I can’t help but feel irritated when I come across poor writing from competent people. Honest mistakes happen – everyone does them – but it is easy to spot when mistakes come from laxity rather than the occasional moments of inattention. My belief is that you should never do any less than what you’re capable of (and always try to improve – but that would be a topic for another day).

No excuse – What irritates me most, however, is poor professional writing. By professional writing, I mean any writing which is published or displayed publicly; any writing that anyone could read, or that a specific audience could read, or that is meant just for you by a person or organisation with whom you have a non-personal relationship. In fact, professional writing is any writing that is not personal in nature: a teacher’s letter to parents, a notification email by the office manager to staff, an article in a newspaper, an information sign in a store aisle, instructions on how to assemble furniture, directions on a bottle of medicine, a pub menu, a post in a software bug tracking system, a plaque on a monument or memorial park bench, a newsletter from a club, an article’s description on a website, source code comments, a road sign, a message in a shop window, a label on a website’s button, the helptext for that button, this blog article, a promotion email, a twit to your followers, publishing in any form… the list is endless.

In these cases, there is no excuse for poor writing. As a matter of course, organisations have, or should have, copyediting and proofreading in place. Publishing houses have professionals for that, but even the smallest of organisation can do reviews and corrections, even if that is an informal position for the office boy who is a wiz with words, or if that involves asking a friend to help. There is no excuse for a poor banner or sign: how many eyes does it pass in front of before it is put up, and still no-one spots the mistakes? The CEO of a company, writing his weekly newsletter, may be too harried to bother with a letter-perfect blurb, but would make sure that his secretary goes over it to polish it. Indeed, an author with high standards is not necessarily one who makes few mistakes, but one who knows his limitations, and who will ensure that his text is reviewed and corrected.

One very disappointing example of poor professional writing is the one coming from schools – places of education and knowledge by definition. The irony is hard to miss when you hear a headmaster or teacher stress the importance of good communication skills and the clear correlation between these skills and achievements in life, and notices on the wall contain grammatical howlers, and the letters you receive are in poor English.

Do it right – You (or your organisation) should make sure that only the best is good enough, because you have a duty of care. You write for somebody. You write to inform, warn, explain, communicate. It is your job, your responsibility, your duty to your reader or readers (whatever their relationship to you) to do it well. After all, you are writing to be read. If you don’t take that seriously, then it is not worth doing in the first place.

I have heard people say “why should I care about [the numerous grammatical, punctuation, and spelling mistakes you’ve just pointed out]? They [the hapless readers] will know what I mean!” Maybe they will (although there is still a greater risk of misunderstanding than otherwise), but you’ll look unprofessional and you’ll make their job (reading) harder and probably unpleasant; that’s never a good thing.

I have also heard, “they [the readers] won’t care about all the mistakes, it’s the message that’s important“. Well, let’s examine that, disregarding the other qualities that bad writing can have, like being confusing, misleading, or having a different meaning than the one intended. To generalise, your readers will be made of two types of people: the ones who care, and the ones who don’t care (or can’t tell the difference). The ones who don’t care – you are right – won’t care. The ones who care won’t like it. Now, let’s say that you do a good job. The readers who don’t care still won’t care. The readers who do care will be happy. Net win if you do a good job. Whichever way you look at it, badly writing a message only makes it worse – never better. Bad writing will provoke reactions (e.g. irritation, puzzlement) that will also distract from the actual message, which is the opposite of the desired effect. Can you imagine a funeral invitation such as “Your invited to bobs funeral. well celebrite his life“?
Of course, if you still don’t care, then nothing I say here will change your mind, but if so, then please don’t use that excuse – it’s nonsense.

And if duty of care really doesn’t sway you, then think of how you are perceived, of the professionalism (or lack of) that you project, of the effect on your customers.

As for a specific example, what is it with people and apostrophes? A lot of people don’t use them at all. Carelessness? Sheer incompetence? Fear to get them wrong? Some people seem to scatter them randomly, maybe hoping that a few will land correctly. Some often write most possessives without apostrophes, and tag “‘s” to most nouns to make plurals (and not consistently either, which implies that it’s not even logically done). Of course, the fact that for so long teaching English was not actually in the curriculum is not helping those who would like to get it right. The worst and most typical abuse is “its“…
No, “it’s” is not written “its” (and vice-versa, although that occurs less often).

A lot of bad writing occurs because people write phonetically; they just write as if they were speaking, using whatever words fit the sounds. Unfortunately, you can’t just do that; written English is in practice a different language than spoken English. If I just say “my friends coats” (ignore the writing for now) in a conversation, you would have to determine from the context what it is that I am talking about. However, I can write “my friend’s coats” (my friend has many coats), “my friends’ coats” (my friends and their coats), or even “My Friends coats” (coats from the just-launched ‘My Friends’ brand of clothing), all with different explicit meanings.

In a TK Maxx in town, there is “kids, shoes, accessories” all over its windows. Does it mean they are selling kids? Hmm, no; just next to that, there is “mens, womens“… An 8-year old would know better :-(.

We have a church of St Andrew here. There is a sign on it with “St Andrew’s Church“. Not far away is “St Andrews Day Nursery“. Next door is a club, with “St Andrew’s Men’s Club” above the door but “St Andrews Men’s Club” on a banner outside. The road sign says “St Andrews Road“, of course. Sigh…

It’s everywhere: “im“, “ive“, “dont“, and “whats” (apostrophe allergy), “manufacturers warranty“, “1 days notice“, “The Worlds End” (yes they do), “families holiday” (for “family’s holiday”), “mens“, “womens“, “childrens” (double plurals?). What is it, is your keyboard missing a key?

And of course you have these homophones differing only by an apostrophe, like “its” (already mentioned), “lets“, “wont“, “cant“, “well“, “were“. Yes, these mean something different; that’s the way it is.

And no, more than one photo is not “photo’s“. I suppose you would describe its frame as “the photos frame was lovely” then? One pub I went to recently had its menu written without a single apostrophe when it needed about a baken’s dozen of them. On the blackboard however, it was “ice cream’s” and “pudding’s” galore. Nice food though :-).

Apostrophes really are simple, there is one rule to bind them all.

As for other homophones, in particular grammatical ones, my favourite is “your” (“your so funny!“…hmm). “Its” and “your” make me shudder. Other famously misused ones are “their/there” (for “they’re”), “of” (for “have”), “who’s” (for “whose”). Furthermore I’m sorry, but “2” for “to” and “4” for “for” have been used to death – give them a rest.

Some people can’t even copy some text without making mistakes: I have never seen a “Kings Road” turn magically into “King’s Road”, but I have often seen a “King’s College” turn into “Kings College” (where’s that damn key again?). The reason for that is probably the same as for incorrect writing in the first place: writing phonetically – never mind what was written in front of your eyes in the first place.

Finally, if you think that this is a problem just with English, fear not; it’s just as bad, and sometimes far worse, in other languages. French is not easy, I know, and I have seen some truly awful written French. The sad thing is that English grammar is so simple in comparison. Oh well, I guess you need perspective to be able to realise that.

And don’t get me started on punctuation…

Posted in Thoughts and opinions | Tagged , , , | Leave a comment

Quality is important

I meant to write a small post on why it’s important to write software of the highest quality, but it turns out that I don’t need to – many others have done it better. Instead, I’ll write about what it means to me.

But first, what is quality? Lots of things, as it turns out, and there’s an excellent article here that explains it – there’s no need for me to repeat it; it’s all there.

Of course, from the article clearly flows that quality is important because of what it brings, of what it achieves. Without quality, you will not have a product that works, that is usable, reliable, efficient, maintainable, that lasts, that sells.

Each type of quality is important; the only variation is how it applies to you. For instance, marketing quality is important, but it’s not directly so to me because marketing is not what I do. On the other hand, I have a direct effect on the quality of the software I develop, and if I don’t see it as important, the likely low-quality result would detrimentally affect everything else – that’s not good.

Consequently, quality in my opinion is a question of competence, undoubtedly, but the key is attitude. If you haven’t got the competence (*), or can’t improve it, then maybe what you’re doing is not right for you – there is no shame in that. But attitude is crucial: if the quality of your work is not important to you, then the result will be bad for everyone.

That leaves the last question: how do you rate quality? Some industries have yardsticks, but the software industry is still finding hers; software engineering is still an art to a great extent. However, certain aspects can be verified: software should produce the results expected from inputs; its robustness can be evaluated; its efficiency can be measured. Other aspects are more difficult to evaluate, e.g. good design to induce simplicity of use and, if required, flexibility; complexity not implying complicated software; clarity and structure for ease of maintenance, debugging, and extensibility. Developing quality software means paying attention to all these aspects. Quality will be rated by facts as well as by your peers and betters.

So to me, quality means trying to do the best possible – it’s important. That also means that I really desire quality from others, since just like I would want to give them my best, why shouldn’t I hope for the same from them? As a parting thought, here’s a truism: remember that if you aim low, you will never reach higher – aim for high quality, and you can always adjust your reach to circumstances.

(*) Competence, not skill. Skills can be learned, and either you become competent at them, or you don’t.

Posted in Thoughts and opinions | Tagged , , | Leave a comment

So what about calculators collecting? (part 1: self-pity)

Everybody needs a calculator or two hundreds don’t they? No? Oh, maybe it’s just me then.

At it happens, I am not the only one, so I feel slightly reassured by the fact that my disease is not unknown, that I am not the only sufferer, that it is recognised, and actually internationally shared.

Let me state my case: back when I was a spotty 16 years old high-school student, I managed to acquire an HP-41CV. That won’t mean anything to most of you, but it was a programmable calculator, one of the best at the time, an extremely (relatively) expensive Hewlett-Packard model. It wasn’t my first programmable calculator – I had had a TI-57 (from Texas Instruments; its entry-level model) for a few years; but it was my first serious one. It was more a computer than a calculator, really (and was marketed that way), and it was the bee’s knees, übercool, nerd-tool extraordinaire; it impressed my class-mates and helped me through school.

A couple of years later, I started engineering school, and needed something beefier. I would have been happy to keep my 41CV and expand it, but HP was very expensive, and I didn’t have the means. So I sold my 41CV (sob!) and with the proceeds bought the latest Casio model, with a plotter, tape drive, lots more memory, a qwerty keyboard, BASIC programming, and a 160×32 pixel screen – “whoa!” – yes, I know!  That machine, a PB-700, is still fully functional and in excellent shape.

Not asleep yet? Ok… It was the early eighties, the “calculator war” was on, technology was progressing by leaps and bounds (as it still does), whatever. Thing is, I always regretted parting with my HP-41CV…  Many years later, in early 2008, I was idly wondering (now that money was no object) if I could get “back” my HP-41CV, and who knows, maybe buy the “accessories” this time (card reader, wand, printer, plotter, software modules, RAM…). Could I? Oh yeaaaah!! Hurray for eBay!

So I got an HP-41CV.
… I wondered about a spare (in case things went wrong), so I got a spare.
… I bought accessories (which are many and varied), with spares.
… I also found the next model, the HP-41CX, and bought one, and a spare. And a spare for the spare.
… I also got to musing about other HP models that had fascinated me back then, or that I didn’t know about then and fascinated me now, so I got them too. With spares.

Before you could say “calculator”, I had become a collector, and the subject of major ribbing at the office (where I got things delivered). I was as a magpie to a piece of glass, a seagull to an ice-cream cone on a windy seafront, a dung beetle to a … er, well, you get the picture.

The problem is that, as far as mid-life crises go, this may be less physically dangerous than taking up motorbike riding, but this is actually risky in other ways: expensive, addictive, vast; and the amused tolerance that greeted me at the beginning turned into an scowl.

I do have at least 300 calculators  (I lost count a long time ago) and also a few computers. Some are more antique than others, some are working and others not. They are from Hewlett-Packard, Texas Instruments, Casio, Sharp, Canon, to name just a few of the main manufacturers.

The result is a mess: boxes everywhere, heaps growing in corners, dust all over the place; I would often buy a box full of stuff just for one piece of kit. I have duplicates, triplicates, quadriplicates, multiplicates. I’ve also got printers, RAMs, ROMs, cards, packs, pacs, wands, tapes, rolls, pads, modules, cables, styluses, reams, pouches, cartridges, sleeves, CDs, floppies, overlays, drives, chargers, cases, DVDs, ribbons, a stockpile of NiCd batteries, and a Macintosh Classic. I’ve got books, manuels, leaflets, flyers. I’ve got repair kits, pliers, tweezers, solvents. My oldest calculator is from 1974; my youngest from 2013. I’ve got VFD, LED, LCD, CRT.

My resolve, some years ago, was to stop the silliness and get organised. Now finally, I’ve started – earlier in the summer. It is slow going, but I am making progress – I have done all the calculators from HP except the 41C ones. As things stand, that’s probably about 20% of my stock sorted out. Later on, I will put back on eBay all the machines that I’ve decided to part with.

One of the good things about collecting, no matter what you collect, is that you meet people: I’ve been in touch with enthusiasts, experts, amateurs, from all over the world. It’s a very dynamic world, very lively, very friendly.

Are old calculators dead? Far from it.
Am I a bad case? Oh no, no, no: some people I know have thousands of calculators… and you thought I was bad 😉

Posted in Calculators | Tagged , , , , , | 2 Comments

Email musing: so, what are these P1 recipients then?

Have you heard of them? No? I’m not surprised, this is kinda technical stuff, but in what I was doing, this was essential. In a nutshell, P1 recipients (I’ll explain later why they’re called that) are the actual recipients of an email at any given staging point that the email, or one of its copies, goes through on its way to its destination(s). There, simple. You wouldn’t believe how many people didn’t get it (not you, I’m sure). More often, people confused them with Bcc recipients, but there’s a reason for that: a lot of people don’t understand Bcc recipients either.

You’ve all heard of To, Cc, and Bcc recipients, right? Well, at least the first two kinds? Let’s have a refresher:

‘To’ recipients are the names or addresses that you enter on the To line/box when you compose an email. These are the people (or whatever, e.g. shared mailbox info@wordpress.com) that you’re sending the email to, sending directly to.

‘Cc’ recipients, where Cc stands for Carbon Copy (from the good old days when you used carbon paper to make mutiple copies of a letter on a typewriter), are the people that you’re sending a ‘copy’ of the email to. They’re not directly concerned, you’re not ‘talking’ straight to them, but nevertheless you want them to know.

You’re also making implicitly clear, to anyone on the To or Cc list, of who else you’re overtly sending the email to. That’s because the To and Cc lists are part of the email’s content; they’re visible to anyone reading the received email.

Right, at least this distinction was the intention. I’m sure plenty of people never use Cc and just bundle everybody in To (or worse, bundle everybody in Cc and leave To empty), but the goal here was clarity: if you send an email to Bob and Alice, and write “Hi there, I thought you might want to go out on a date with me tonight”, you’d better be sure that you mean that you want both of them to come. It’s like good punctuation: it makes things clear. Now, if you wanted to ask Bob out, and just wanted Alice to know (and Bob to realise that Alice would know), you’d put Bob as a To, and Alice as a Cc. Bob would receive the email and realise that you’re asking him out, but also letting Alice know. Alice would receive the email and realise that it’s addressed to Bob, but that her name is clearly there in the Cc list, because you wanted her to know, and Bob to know that she would know. Keeping up?

What about Bcc recipients? Well, now imagine that you’re asking Alice out, and want to let Bob know, but without Alice realising. Simple: put Alice in To, and Bob as Bcc. Bcc stands for Blind Carbon Copy. ‘Blind’ because none of the other recipients (the To and Cc ones – Alice only in this example) knows that a copy of the message is going elsewhere; they are blind to it. This works because whatever you enter in Bcc never appears in the text of the received email, never ever. Whatever you enter in Bcc is like a command you give verbally while handing out a written message – it’s not written down.

But this is where confusion arises. Because once the mail is in transit nobody knows what the Bcc recipients were to start with, people imagine that any recipient that the email server knows about, but is not  listed in the email content itself as To or Cc, surely must be a Bcc recipient. Right? Nope. The thing is, To, Cc, and Bcc only mean something to you, the guy composing and sending the email. The email system itself, on the other hand, couldn’t give a hoot. Its job is to deliver the email to a list of recipients. That a recipient was a To, Cc, or Bcc recipient, is of no relevance – that fact only mattered to you.

So what are the P1 recipients then? Well, they are these recipients I just mentioned whose types the email system doesn’t care about… with a twist:

Let’s imagine, going back to our last example, that Bob works in the same company as you (“ACME”), and your boss is paranoid (let’s call him James) and wants a copy of every email you send. He bribed the email administrator to set up that rule. Alice, on the other hand, works for a different company (“RRLtd”), and no-one snoops on her emails. Both your company and Alice’s have basic journaling in place (where a simple copy of every email is kept in an archive).

This is where your email is actually going:
(Note: for the sake of simplicity, the following stages are not completely accurate.)

  1. When you composed the email, you entered Alice as a To, and Bob as a Bcc.
    The P1 recipients at that point were simply Alice and Bob.
  2. When you clicked “Send”, the email first got to ACME’s mail server, which promptly added your boss as a recipient, and also the journal mailbox (for archiving).
    Now your P1 recipients are Alice, Bob, James, and ACMEJournal.
  3. Because Alice is in a different company, at that point the email ‘forks’: a copy of it goes to RRLtd, while another copy stays at ACME.
    The P1 recipients on the copy going to RRLtd are Alice – nobody else.
    The P1 recipients on the copy staying at ACME are now Bob, James, and ACMEJournal.
  4. When the mail server at RRLtd receives the email for Alice, it adds RRJournal as a recipient (for archiving).
    The P1 recipients now on that copy of the email are Alice and RRJournal.

When James gets the email, he will see that you sent an email to Alice. He won’t know about Bob.

When Alice gets the email, she’ll only see herself as a recipient.

When Bob gets the email, he’ll see that it was sent to Alice, but won’t see himself as a recipient. If he’s smart, he will guess that you sent him a copy as a Bcc recipient.

The journals, they don’t really care, they’re not human, but if the email administrators of ACME and RRLtd have a look in their respective journal, they’ll simple see an email from you addressed to Alice.

So, as you can see, there were here lots of various lists of P1 recipients, depending on where the email was, and which copy it was. And as we saw, in all but the first stage this had little to do with who was actually entered as a Bcc recipient.

Why is it wrong to work out the Bcc recipients from the P1 recipients?

For two reasons: one, as I explained, Bcc recipients only mean something to you the sender; and two, you’d be asserting something that the sender didn’t actually set up(*):

At stage #2 above, if someone takes the P1 recipients and remove from the list any recipient that the email’s content says was a To or Cc recipient (itself a flawed process – maybe for another time), and then says “what’s left are the Bcc recipients”, then the Bcc recipients would be given as James, Bob, and ACMEJournal. But you didn’t enter James and ACMEJournal as Bcc recipients! Piffle? Well, if your company has a compliance policy that prohibits you sending emails to James, you’ve just been caught and labelled a traitor. Nice one.

(*) Again, except and only at exactly the first stage in the email’s travels, when P1=To+Cc+Bcc.

Conclusion: Bcc recipients are not P1 recipients.   P1 recipients are not Bcc recipients, or even a superset of Bcc recipients.   P1 recipients are where an email is going, seen from a specific point, for a specific instance of the email.

So, why are P1 recipients called P1 recipients? It comes from the terminology of the X.400 email standards, and “osmosed” its way into Internet emails lingo (via Microsoft Exchange, which was based on X.400/X.500 at one point). P1 was the protocol for inter-Mail Transfer Agents communications. P2 was the ‘protocol’ for message contents. For instance, the body of an email is P2 data. To and Cc recipients will be listed in the message (somebody receiving the email will see them listed), so are P2 data too (and they also feed the original list of P1 recipients). The Bcc recipients are not P2 data, they only feed the original list of P1 recipients.
When applied to SMTP, the P2 data/content is what’s given to the DATA command, i.e. it’s the actual Internet message to pass along. Headers in that Internet message are therefore sometimes called “P2 headers”. The P1 data/content is the ‘envelope’ information, e.g. the MAIL FROM command (the sender’s address), the RCPT TO command (a recipient’s address); all the information required by SMTP for the email’s transmission. These commands and their content are sometimes called “P1 headers”.

Posted in Email musing | Tagged , , , , | 2 Comments

Gosh, a blog…

Oh no, not another one!

This is a slightly cynical move on my part, as it was suggested to me that blogging would increase my online visibility, which is a good thing as I am currently “seeking new opportunities”. So here I come.

However, it is true that I had been tempted to blog before. It’s just that I couldn’t think of things that I thought would be really interesting to write about for anyone out there to read; or that there wouldn’t already be ten  similar discussions on the same subject – why add to the noise? Also, sometimes (always?) we software engineers really think that the stuff we do is dead-boring to anyone else. Well, yes, ok. Still, some people may be interested. Maybe. It could depend on how it’s written.

A note about my name. When my parents gave it to me, they didn’t realise that all my initials put together made “PHYL” (my middle names are Heinz and Yves). Besides the amusing fact that this pronounces like a shortening of my first name, this is handy for the online world in which we live: it’s good that  my everyday name is not that common to start with, but if I also use my initials, then I’m getting pretty unique (as far as a Google search assured me). So, this explains why my blog’s address starts with phylasnier.

Let’s see now how this blogging thing is going to pan out…

Posted in Everything else | Leave a comment