Fear Me

Save more time, make more money!
Only Nitix sells with bunnies!

Yeah, you'd better hope I'm only kidding because it's April 1st. I certainly do.

From the Peanut Gallery

I realize this is Advogato, so you're expecting me to say something about coding. But as I am quickly realizing, poetry is much more relevant to a programmer's life than you might normally assume. So I'm going to just pass along the cheesy poetry people send me; it's really the least I can do. The least. Really.

-- Easter Dinner -- Will poetry cause Nitix sales to grow?
Quite likely, not worth a damn,
But what your mother wants to know,
Is do you want turkey or ham.

Just so you know, the above shows a slight misunderstanding of my overall marketing strategy. Come on, poetry doesn't make people buy stuff; that would be ridiculous! Poetry just gets their attention. It's the photos of cute fluffy bunnies that will make them buy stuff.

Uh, ham, please.

Precious Instability

In my Control Theory class in university, the prof gave an example in passing about fighter jets. A modern fighter is so completely controlled by the computer that if the computer fails, the jet would fall out of the sky pretty much instantly. Why? Because the mechanical design of the jet keeps it aerodynamically unstable. You can certainly build a plane that, if you stop steering it, will mostly continue to go in the direction it was going before. But with fighters, they intentionally do the opposite. That way, if you control it properly, you can make it go straight if you want, but you can also make it turn very fast, because turning fast is what the mechanical design does all by itself.

That story resonates with me because it agrees with how I try to run my life: very in control, very fast, and very manoeuverable. But it's hard to achieve that kind of speed: it works because I don't tie myself down into any one course. I'm constantly being pulled in a million directions, and which direction I go is constantly a new choice, every minute of every day. The fact that I happen to choose fairly consistently is my own doing, not a side-effect of the environment.

If you understand that, then you understand that it's not surprising at all - not even difficult - for me to be leading a development team one day and doing pure marketing the next. Like a fighter jet, the amazing accomplishment is that it ever goes in a straight line, not that it sometimes turns in surprising directions.

But there's a second part to the story from my Controls class. Most airplanes aren't designed that way at all: most of them are designed for stability and safety, and slow turning speed is taken as an acceptable tradeoff. In an airliner with hundreds of people on board, you can't take the chance that a simple miscalculation or malfunction will send everyone flying straight into the ground. And the more people you bring along with you on your flight, the more critical it is that your airplane be designed for stability.

It's not fair to risk the fate of everyone just because you refuse to commit to something.

More Poetry

Thanks to sforman and wlach. That's right, you too can have your name in lights!

Accpac is good; Nitix is great.
I really like Nitix for Sage Accpac ERP
on my hard drive plate.

Disclaimer: Uh, Accpac is also great. Please buy it too.

Need Fulfillment and Loyalty

In an entrepreneurship class a long time ago, my professor explained a theory in psychology that there are three main kinds of motivation, and for each person, one tends to be dominant. The three motivations are: nAff (need for affiliation), nPow (need for power), and nAch(need for achievement).

Let's look at these in terms of company loyalty. You'll stay with a company if your job fulfills, or promises to soon fulfill, your dominant need. So what would make you leave? Well, if your job no longer promises to fulfill that need.

nAff is about friendship and acquaintance; you like your co-workers and you feel secure in your relationships with them. A highly disruptive event, like layoffs or restructuring or switching to a totally different team with little contact with your original co-workers, or a series of such events, can greatly reduce your nAff fulfillment. Similarly, if other people you know are deciding to take jobs elsewhere, you'll consider leaving too. Think of it as chasing after your nAff.

nPow is partly about having power (over people), and partly just about the prestige of having power over people. As long as you believe that other people believe you're important, you can generally fulfill your nPow. Conversely, finding out that someone just got promoted into a spot right above you, or finding out your team isn't so important after all, or, for a manager, finding out that your company isn't destined to be the next Amazon.com (when you previously thought it was) can be a big blow to nPow fulfillment.

nAch is not about people thinking you're important: it's about actually being important, even if it's to a project only you think is important. To see the difference between nAch and nPow, think of it this way: people with high nAff or nPow can't be happy alone; high nAch people might be perfectly happy on a desert island, if that's the best place to accomplish what they've been trying to accomplish. (Of course, some kinds of achievements require people, eg. customers.) nAch fulfillment isn't hurt much by imminent failure or by people telling you your goals are useless; those just make you work harder. But being prevented from achieving your goal, or finding out that the goal you've worked at for years is not useful after all, or finding out that your goal could be achieved with or without you - these cause serious nAch problems. And this can look confusing: even when you're highly productive at your current job, if you realize that someone else could do it sufficiently well, you feel as if you aren't achieving your potential. I know at least one person who left NITI because of this. High-nAch people are very hard to retain for long, particularly if you don't have an endless stream of serious problems to solve.

Incidentally, most geeks are nAch-dominant. Most managers are nPow-dominant. And most humans are nAff-dominant. Every company needs all three, although salaries do tend to be affected by the laws of supply and demand.

Look at the people around you. It's actually very easy to see which people have which primary need; everything they do reflects it. In a few cases, you can also see an unusually strong secondary need.

Money

While we're applying "needs theory" to employee loyalty, you might be tempted to add a fourth need: nPAY, the definition of which you can probably guess.

In fact, the need to get paid is just a proxy when your job is not really satisfying any of your other needs. If you hate your co-workers, feel helpless to change them, and think your job is a waste of time, you might still do it if they pay you enough. That's because you feel that the money allows you to fulfill your primary needs outside work. For example, having a steady job allows you to hold onto a family, having lots of money makes you feel important when you buy stuff from a lowly salesguy, and being financially stable means you have the resources to accomplish things that might take money as well as effort.

Interestingly, from this point of view, money isn't just a proxy for goods and services; it's a proxy for satisfaction in any of three different forms. Who says money can't buy happiness? If your job is totally unsatisfying in the other three ways, you'd better hope it can!

Modern Hygiene

The T&T supermarket has a "meat floss" aisle.

That is all.

Design Gems

Normally I'm a programmer with a high output rate, which means that I can turn ideas into code pretty quickly. But what with my self-imposed marketing responsibilities lately, I've had almost no time for coding.

The problem is that I still think about coding. So my designs are ever-improving, while the amount of code I write has been ever-decreasing. A few times lately at work I've gotten caught explaining how I remember certain code working, only to find out that I only imagined it that way in excruciating detail; nobody implemented that feature or even talked to me about it yet. Oops.

But another weird effect from this is that my code design quality is improving. I spend so much time pre-considering things lately that when I finally actually write it, I've got it all figured out. But it results in what I will name the "pphaneuf syndrome": the problem is solved so thoroughly by so little code that nobody can believe your code actually solves the problem... or that you did any work.

Here is my example:

The Gracefultavi "Attach" Plugin

GracefulTavi is the wiki we use for our internal documentation. Over time, it's been used for more and more things, and we're finding the need to write more and more "formal" documentation (eg. specs that need to look nice for presenting to clients, who will sign a contract to pay us hundreds of k$ for implementing them).

So our first problem is simple: the wiki has all our development information, cross-referenced in different ways, because we've used a wiki since day one and we've done all our development documentation (with a few, ironically unremembered, exceptions) in the wiki. But it's not customer-grade documentation; sending customers wiki page dumps is pretty lame.

Secondly, even when no customer contract is involved, writing specs in wiki format is really annoying, because (like most traditional wikis) GracefulTavi doesn't support attachments and screenshots. As with any html, you can link to outside attachments and images, of course, but these are hard to administer properly and definitely break with the "anybody can fix your mistakes" wiki tradition.

Thirdly, we're trying to implement internal processes whereby (for example) even an internal spec can get signed off by several people and that version becomes completely tamper-proof: despite the "anybody can edit" wiki tradition, anybody can edit, but nobody can edit that version. And that version might contain images, tables, attachments, and so on. And there will be more versions after that. And you might want to refer to those same versions of those images and attachments from other pages even when new versions appear (for example, the "1.0 test results" want to reference the "1.0 test plan" even after 2.0 is released).

Thanks to mich and kjrose, it's easy to add new macro plugins to GracefulTavi. So I did... in about 1.5 hours. But that very short time was possibly only because I thought about it so much first. (*)

Other wikis, like MediaWiki also support attachments, but in a much more extensive way that took a lot more coding effort. Here's how my solution works. For most purposes (probably not WikiPedia), mine is better. You don't have to believe me, but it's true.

My attachment plugin has only three concepts: upload, delete, and lock. (There's also "undelete" and "view", but those are too obvious.) Upload is simple: a non-uploaded attachment is empty, and has a file submit button. Delete is simple: an uploaded but non-locked attachment has a delete button, which will permanently delete the file and let you upload a new one. And lock is simple: an uploaded but non-locked attachment has a lock button, which will permanently protect the file from deletion. Preventing deletion, in turn, prevents re-uploading.

The filename space is global. That is, across the entire wiki, if you upload a file called "foo.txt" and lock it, that's it; there will never be another foo.txt.

Despite its ridiculous simplicity, this model is not nearly as obvious as it sounds. Permanent deletion - in a wiki? Permanently locked documents - in a wiki? Names that nobody can ever change ever again? An attachment scheme with no revision history or version control - in this day and age?

Yes, yes, yes, and yes. And only those four things together make it work. In other words, breaking any of those "common sense" rules would have resulted in an unusable system; breaking all four of them at once is why it works.

Here's why. First, the wiki already has revision control; adding another versioning layer for attachments would be inelegant. Instead, what you do is encode the version into the filename. Sounds lame to you, Subversion users? Just remember, the kind of people who prefer binary documents to wiki documents are exactly the kind of people who don't like Subversion either. Furthermore, fully revision controlling binary documents isn't useful, because the diff/blame/branch/merge features don't work anyway. And auto-assigned revision numbers are meaningless, while human-assigned ones are memorable. And because you can't re-upload a locked document, nobody can change your document once you're sure you've uploaded it correctly - in other words, we implement the one remaining feature of Subversion that's actually useful for binary files.

So you can easily do 100% protected revision control with my plugin, which doesn't even support revision control. Don't upload "myproject-spec.doc" - upload "myproject-spec-1.0.doc", ie. the 1.0 version of the spec - and lock it. From then on, anybody who wants to talk about the 1.0 spec (on any page in the wiki, past, present, and future) will be confident that they're talking about that exact file. And the MyProjectSpec wiki page can link to that file for now... and in a future version, it can link to "myproject-spec-1.1.doc" instead or in addition. What did the spec look like last September? Go back in wiki history and view the hosting page, and it definitely points at the same attachment it did at the time. No magic auto-assigned rev numbers to remember, no branches, no tags, no syntax, and no uncertainty.

The pent-up demand for this was obviously huge, because within days it was being used all over the place in the wiki, and the usage is ever-increasing. Meanwhile, some people are still ironically claiming that it can't possibly solve the problems it intends to solve.

I say... the results speak for themselves. Which is good, because the above explanation is really long and confusing.

Off-topic Disclaimer

(*) People will say that we could have saved a lot of time arguing about it internally by just doing the 1.5 hours of work in the first place, but that't not how design works; I wouldn't have spent so much time (much more than 1.5 hours) thinking about the problem if there weren't so many arguments about it before. And just leaping into coding with a bad design would have taken more time than thinking/talking about it first.

R.E.

The core of any design, whether it's a painting, a building, a computer program, or a company, is its "Raison d'Etre" - its Reason for Being, or, with conveniently the same initials as the French version, its Reason to Exist. Its RE.

Your skill as a designer depends on your ability to clearly imagine an implementation for your RE. And the degree to which the different implementers of a design understand its RE - or else, the level of control you give you people who don't understand the RE - strongly affects the overall coherency of the result.

Let's say the RE of your software project is the customer requirements or functional spec (they're different things, but since one leads directly to the other and they both come earlier in the pipeline, you could think of either one as the RE of the software). For some software, this isn't the case; some software, like Plan 9 or Scheme, exists for some other kind of RE that allows it to attain beauty while sacrificing usefulness. But in general, software with customer needs at its core is the kind that makes money, and it still has the potential to be beautiful. And as we all repeatedly learn, software which is beautiful can easily still fail to make money. The two attributes are really independent. But the kind of software I really like, the kind that makes money and is beautiful, works because it's consistent with its RE (ie. it's beautiful), and its RE is a well-defined set of customer needs (ie. it's useful).

A company's design works similarly, but there's a problem: as you progress through the technology lifecycle, the way you service the market needs to change, so if your RE was based on a particular way of acting - for example, doing heavy research for the early market - it obsoletes itself. The result is a strangely rotten core around which you've built a highly consistent implementation; you remember the beauty that existed before, but now that the core is different, the beauty is gone, even though the implementation is exactly the same. And trust me, although no person is to blame, the designer finds all this to be rather a PITA. People who enjoyed building something beautiful don't want to continue working on the implementation if they know the result won't be appreciated anymore.

Imagine you're writing a love letter to someone, and it's coming out really well, and suddenly you realize that person actually has really bad breath and glowy red eyes and you don't love her after all so you break up. As soon as this happens, the work you've done so far will go sour. Strangely, people who don't yet understand the newly-discovered flaw can still see the beauty of the work you've done so far, because they imagine a RE that is still there. But you, the artist, will never be able to honestly finish the work. Since beautiful work comes from an honest implementation of the RE, once you know the RE is gone, you will find that everything you do just makes it worse. If you're famous enough, it's better to just leave the unfinished work in a museum so a curator can dust it off occasionally and sell retouched reprints at huge profits. At least then people can continue to admire the beauty that once was. Don't ruin it by trying to keep building a fake implementation around a RE that has been lost.

Meanwhile, just as a work of art is meaningless without a RE, so is an artist, and a good artist won't take long before finding a new RE. If he's lucky, it will be one that's as compatible as possible with the old implementation; even the old implementers.

It's time to fall in love again. And we've got a half-written love letter that we can recycle. I'll show you how.

The Spark

There are some people who just can't help it - certain things just go better when they're around. I write about design a lot, but you can lack design ability and still make things better. And it's not really about motivation, because it can happen despite your every intention to stay out of the way. It's not even about raw skill or talent - there are lots of people with great talent who go nowhere because they don't use their talent for anything. A combination of design, motivation, and talent can be a powerful one, but that's not it either; that's just a good substitute, in case you don't have it.

Let's call what I'm talking about the "spark." Think of it sort of like a nuclear reactor in a person's core, spewing energy and radiation everywhere. Sure, you can direct the energy and do amazing things; but even if you don't direct it, or you consciously try to contain it, the excess energy has to go somewhere. It leaks out, or it explodes.

I have great respect for motivated, talented people. Plop them into a well-defined engineering or business process, and good, useful things get produced pretty efficiently. That's nice.

People with the spark aren't quite the same. They might also be motivated or talented or both, but they might not. The spark isn't exactly an object of respect - it's more an item of curiosity. People with the spark are interesting. People without it, however nice, or useful, or productive they might be, aren't.

The spark is hard to isolate, because its symptoms are mostly the same as symptoms of other things - motivation or talent, for example. I make a game of trying to see if it's there or not. This turns out to be a useless skill by itself, because a spark, by itself, is uncontrolled energy that will mostly just randomly change things. To actually accomplish a major goal, you need more than just a spark; you need the motivation to follow through, and the talent to be able to fill in all the extra details.

Still, there are reams of books written about how to keep people motivated, and how to train people to improve their skills, and how to identify people's key talents. All those things can be added on later. But I don't know how to generate a spark that's not there.

The most interesting people to me are the ones that have the spark, but are failing to get anything out of it. They have the energy, but they don't know how to control it, and the leaks are just random. With just a few little tweaks, you could get something much bigger, much more useful, and at least a little bit less random.

The most reliable way I've found to identify people with a wasted spark is this: they keep producing small, good things, but can't explain why, and can't seem to sustain something bigger. Some entrepreneurs have the spark, but many fail because they lack dedication or the right skills. Some artists have the spark, but many just have enough skill and dedication to fake it convincingly to the untrained eye.

I'm convinced that all the really interesting things in the world come from one person's spark; the tragedy is how few of those sparks actually go anywhere in the end.