« Posts under General

Growing a Solid Software Company — Update

Yesterday, on October 21, all Lufhansa pilots went on strike in Germany. Nevertheless, Lufhansa managed to conduct half of their flights. They achieved this miracle by using a two-fold strategy: subcontractors and — lo and behold — their own managers, who, according to Lufthansa, work in most cases as part-time pilots, anyway.

Pilots that manage, managers that fly. Exactly my words, friends, exactly my words…

Let’s sing a song together, shall we?

I see trees of green, red roses, too,
I see them bloom, for me and you
And I think to myself
What a wonderful world.

Growing a Solid Software Company

Isn’t it a shame that so many software development managers don’t code anymore?

Since I am in a malicious mood today, I claim that they didn’t even write much code when they were still developers. But does it always have to be like this?

After years of deep contemplation I’ve come up with this rule:

Managers, regardless of their position in a hierarchy, should spend at least one-third of their time doing the work of their immediate subordinates.

Not only would this mean that every manager is productive and actively contributes to a project; it would also mean that managers stay current from a technological point of view. Especially the latter would ensure that their strategic decisions are based on much firmer ground.

Wouldn’t performance appraisals (and promotions) suddenly become more objective and fair? Wouldn’t it be much easier for managers to hire new people since they would know — from first-hand experience — what exactly to look for?

If this recursive rule were applied, even the software manager’s boss would write small parts of the software himself. His boss, in turn, would probably not code that much but maybe do some code-reviews or check the nightly build for compiler warnings.

Wouldn’t the code quality be much higher if developers knew that someone way up the corporate ladder scrutinizes their work and gave feedback? Wouldn’t everyone feel much better because they knew that their bosses really cared for what they do?

This is a rule for building up a hierarchy of software craftsmen, a rule that yields what I call a “Solid Software Company”: A company were everyone is a developer (at least to some extent), where everyone understands software’s true nature and developer’s needs.

Imagine you could travel back in time, to the early days of a once hip, now bureaucratic, politics-laden, inefficient, dreadful-to-work-for monster of a software company. You will arrive at a point at which they suddenly start to promote or hire people to be “just managers”.

So, viewed from a different, more negative angle, my rule can be rephrased like this:

The long and slow demise of a young, aspiring software company begins when its software development managers cease to write code.

Growing a Solid Software Company — Update

The God’s Equation for Perfect Highballs

“Mix a stranger a good drink and no longer will he be a stranger”
— Yours truly

I’ve never been a fan of pure mathematics. Even though I must admit that pure maths bears a lot of elegance, it’s real-world applicability that makes mathematical discoveries shine.

Boy oh boy, how time flies! It’s summertime again, at least in the northern hemisphere, on this planet, and what a great time it is for drinking plenty of highballs. For those of you who don’t know: highballs are simple long drinks that are made up of two ingredients: liquor (eg. gin, whisk(e)y, rum) and a non-alcoholic beverage (eg. soda, juice, cola).

Even though there are usually only two ingredients it is not that easy to make a perfect highball. It all depends on the right mixture. Some like their highballs stronger, others lighter. So how do you determine the perfect ratio? The task is complicated by the fact that the strength of the liquor used might vary (for instance, rums come with alcoholic strength levels reaching from 35% to 80%).

So I sat down for a while and did a little math — to solve a real-world problem once and for all. What I’ve come up with is this:

In this equation, Vn is the volume (amount) of non-alcoholic beverage, Vl is the volume (amount) of liquor, R is the mix ratio, Sl is the alcoholic strength of the liquor used and Sh is the desired target strength of the resulting highball. Isn’t this wonderful?

As an example, I happen to like my highballs with a strength of 10% and most liquor in Europe is sold with a strength of 40%. What’s the recipe for a perfect Gin and Tonic? Answer: 40% divided by 10% is four, minus one is three. Therefore, you would need three parts of tonic water for one part of Gin to make me smile.

If you prefer a 5% Gin and Tonic (are you a wimp, by any chance?), note that you will need seven parts of tonic water, not six, as a naive would-be drinks mixer would expect.

There you have it — the formula for perfect, repeatable quality drinks. People in the same spirit (pun intended!) — let’s raise our glasses to this discovery!

Epilog

I know, I know. Some of you smug, mathematically inclined folks with an IQ of 180+ would probably have known this right away. I don’t mind if you point out that my pathetic “discovery” is obviously just a special case of something more profound. Congratulations! I will drink a very special toast to you tonight.

And — just in case you haven’t done the maths yourself in the meantime, here is how I derived it:

Strength of liquor Sl is volume of alcohol in liquor Val divided by the total volume of liquor Vl:

Total volume of highball Vh is volume of liquor Vl + volume of non-alcoholic beverage Vn:

Strength of highball Sh is volume of alcohol from liquor Val divided by the total volume of highball:

Inserting (2) in (4):

Inserting (3) in (5):

Cheers!

Password Sins of Omission — Will They Ever Learn?

“Where have all the passwords gone, long time passing?
Where have all the passwords gone, long time ago?
Where have all the passwords gone?
bad admins stole them everyone.
Oh, when will they ever learn?
Oh, when will they ever learn?”

(With apologies to Peter, Paul, and Mary)

It’s been quite a while but yesterday it happened again: after I had registered with a new electricity provider I was sent an email showing my password — right next to the words “Your Password”. There was also a link that I was supposed to click to verify my personal data, including name, address, date of birth and a lot more things that I certainly don’t want share with the world.

What amazes me most about this incident is that even today some companies are completely oblivious to how easy it is to automatically scan emails for keywords on their way from sender to receiver.

But even if the probability of someone sending around your credentials in plaintext is a lot lower today that ten years ago, the chances of being faced with poor password systems are still quite high. Here is my personal list of the grossest password-related blunders.

1. Storing user passwords. This is probably the greatest of all password sins, especially since it may spawn many other password-related follies. Don’t store passwords, not even encrypted. Instead, salt the password with a random salt and then hash it with a strong hash function before you save it. This way, no rogue admin can run away with your users’ passwords and no crazy customer service team is able to send around mails disclosing credentials.

2. Gratuitously limiting the password character set. I’ve come across password systems that only accept numbers (i. e. PINs), others only a mix of characters and numbers, some would accept special characters like %, &, and ? but not the dollar sign. I don’t see any reason why it’s not possible to use the whole unicode character set; at the very least, all printable ASCII characters should be considered valid. If I wanted to attack a site the very first thing I would do would be to set up an account and find out about their password character limitations in order to prune my search space.

3. Gratuitously limiting the password length. Some folks don’t seem to realize that with passwords, size matters: longer is stronger. An easy-to-type passphrase like “theluckgreensunsdontkiss” is much more secure than the complex, ugly, it’s-so-hard-to-remember-that-I-need-to-write-it-down “B!A7n4$”. While there is good reason to set a limit on the lower bound (I personally would require a minimum of eight characters) it is outright dangerous (read: stupid) to place an upper bound on the length. Be careful: If a site demands a password length of 6 to 8 characters, it is a clear sign that they take security lightheartedly. Maybe they even store your passwords and shorter passwords consume less space on server hard disks. Yikes!

4. Not telling users about limitations. Limiting the password length and character set is by itself a horrible practice, only made worse by not telling users what the limits are beforehand. It is quite annoying if you attempt to set a new password only to be rejected with an error message saying that your password is not in line with the password policy. This has happened to me many times and in one case there was a link to the policy that was broken.

5. No “show password” option. I vividly remember the day when I had to choose a password for a smartcard-based access system at a company I worked for. At the company’s registration office was a terminal that asked me to select a new password for my card. Since there were quite some (gratuitous) limitations (at least one number, a single capital letter, no number at the beginning, no underscore, just to name a few, and they were not displayed beforehand, of course), I had to try several times making minor variations to my favorite password until it was finally accepted. Later, when I had to use it for the first time, I couldn’t remember it anymore. I’m not sure, but I guess that if I had been able to see my weird password in plaintext after I set it, my chances of remembering it would have greatly increased. Normally, I know if somebody is staring at my screen (and this is rarely the case), so why not add a “show password” check box that I can tick? This would also help me in cases where caps lock was on or when I inadvertently switched to a foreign keyboard layout.

6. Setting constraints on the login name. Why does the login have to be an email address (which an attacker is likely to know or which might change in the future), or a number, or an eight character word in all uppercase? One of my web hosters forces me to sign in with my 12 digit customer ID that they assigned to me years ago; I always have to look it up and I always curse the web hoster. Users should have absolute freedom regarding their choice of login name — not only when they create the account; also at any point later in time.

7. Not encrypting passwords before sending them to the server. There are still some sites (and email providers) out there that ask for your credentials without establishing a secure channel first. What that means is that your login name and password are transferred in plaintext to the server and every random wiretapper is able to use it to place adverts to all kinds of shady products in your name. I don’t know how many bloggers are out there using WordPress, but it must be hundreds of thousands; and almost all of them login through a login page that doesn’t use any form of encryption. Even if the NSA is able to read your SSL-protected traffic anyway, it doesn’t mean that you want everybody else to read it, too.

8. Not (or wrongly) using a brute-force attack countermeasure. To prevent brute force attacks a good password system should track the number of failed login attempts. My bank does this but in a rather stupid way: after three unsuccessful tries, your account will be locked and you have to personally go to your local branch office to request a password reset. My suggestion: from three unsuccessful attempts on, have the user wait 10 minutes for every further attempt; additionally present a Captcha to defend against automated denial-of-service attacks.

So here you have it and this is just my personal tip of the iceberg. In order to get real security, password systems need to be both: secure from a technical point of view and user-friendly; at least, they shouldn’t haphazardly limit freedom. The best password policy is worthless (actually dangerous) if it requires users to invent next-to-impossible-to-remember passwords that will end up written down on sticky notes.

Since there are so many sites out there that carelessly deal with passwords and personal user data, I think it is a about time for a law that requires companies to follow certain minimum standards. We just can’t rely on good will and common sense. We have done this for quite some time now and it demonstrably hasn’t work out.

Circular Adventures V: The Christmas Edition

“And the Grinch, with his Grinch-feet ice cold in the snow,
stood puzzling and puzzling, how could it be so?
It came without ribbons. It came without tags.
It came without packages, boxes or bags.
And he puzzled and puzzled ’till his puzzler was sore.
Then the Grinch thought of something he hadn’t before.
What if Christmas, he thought, doesn’t come from a store?
What if Christmas, perhaps, means a little bit more?”

— Dr. Seuss
“How the Grinch Stole Christmas”

Oh well, oh well, it’s Christmas time again. Year after year, in this dark season, people contemplate the circle of life, watch reruns on TV, and rush to shopping malls to buy overpriced items for their loved ones; it is not unlikely, that — as soon as the shops are open again — these loved ones rush to return all the stuff that they don’t really need and buy something cool instead. You can also be sure that the level of madness increases every year — due to a well-known effect that economists call “inflation”.

Since so many things recur around Christmas, this is the perfect time for me to share more “circular” thoughts with you.

But first some background on the origins of Christmas. The reason why people celebrate Christmas on December 25 has little to do with the birth of Jesus, but rather with an ancient Roman cult called “Sol Invictus” (which means something like “unconquerable or invincible sun”). When the Julian calendar system was introduced around BC 45, the winter solstice occurred on December  25 (as opposed to today, where it happens on either December 21 or 22); this day was celebrated as the birth of the sun: on December 25, the sun would come back and rise to its full power over the next months.

It is believed that early Christians also took part in these festivities and celebrated together with the pagans by kindling lights. When the “Sol Invictus” cult was finally replaced by Christianity around AD 300, Christians decided to keep that special day but celebrate the birth of Jesus Christ, instead. (Today, it is assumed that Jesus Christ was born somewhere around March, BC 4.)

But now back to more technical stuff. You might have observed that the weekday of a particular date within a year gets advanced by one weekday in the following year. That is, if first of August is a Tuesday this year it will be a Wednesday next year. But how come?

Being a veteran circular adventurer by know, you should be able to come up with an answer yourself — at least you should try. Don’t cheat. Don’t read on. Think about it.

OK, here you go. A regular year (no leap year) has 365 days and a week comprises seven days. 365 mod 7 is 1, which means that after 52 7-day weeks, there is still this one day left in the old year to be filled with a weekday. You can think of it like this: the old year nibbles away one weekday from the new year and thus weekdays in the new year are “rotated left” by one. For leap years, the “rotate value” is two, since 366 mod 7 equals 2.

Regardless of your convictions, regardless of how strange they might look to adherents of other convictions, regardless of whether or what you celebrate, I wish all of you, dear readers of my blog, a Great Time and the best for the New Year.

More circular adventures…

The “Sofware-Project-as-a-Ladder” Metaphor

ladderThe world of software development is a world full of metaphors. Since its early days, software development has been compared to fields like writing, construction, and even rugby.

Metaphors are important for understanding unfamiliar topics and, yes, even in the 21st century, software development — with its own set of peculiarities — is still unfamiliar to many, including people who have worked in the software industry for decades.

Today, I would like to contribute yet another analogy by comparing a software project to a ladder.

A classic wooden ladder is made of two rails and multiple rungs, mounted together with wood glue.

THE RAILS

No matter what kind of ladder you build — short or long — you need two firm rails that act as a framework for the rungs.

In software development, the first rail corresponds to the people and the second to the process.

It is fairly obvious (and much has been written elsewhere about the fact!) that you need the right people in order to succeed. Right means highly motivated, proactive developers with the required skill set for the job at hand.

But you also need the right process that makes sure that developers are going in the right direction. The process doesn’t need to be heavy and bureaucratic (it shouldn’t be, in fact), but it must ensure that work progresses steadily towards the final product and that no important aspect of the product is overlooked. In short, a systematic process is essential to remove the “chance factor” from a software project.

THE RUNGS

Once you have the rails you can add rungs. Rungs will ultimately determine how long your ladder will be. Every rung gets you higher and closer to your goal.

In software development, rungs correspond to practices. Practices like continuous integration, unit testing, refactoring, static analysis, just to name a few. While the process has long-term, far-reaching influence on a software project, practices are micro-processes, steps that are taken by developers on a daily or hourly basis. Processes are strategic, practices are tactical. Each rung on a ladder only has a small impact on the overall length of the ladder, but it is the sum of all rungs that makes up a ladder.

THE GLUE

To get a sturdy wooden ladder, you have to put wood glue inside the notches. This way, you ensure that the rungs will stay in place, even under load.
Even if you have the best-quality rails and rungs, your ladder will sooner or later fall apart without glue.

In a software development project, glue corresponds to the environment that an organization provides to the team: quality of offices and technical equipment, but also issues like work appreciation, salary, and overtime — in short: how people are treated. These factors influence developer motivation and productivity and whether they will stay with the project and the company. In a bad environment sustained quality work is impossible.

I know that every analogy breaks down at some point but what I like about the “Ladder” metaphor is that it doesn’t favor any particular element. For a successful project, one that delivers a great product on time, everything needs to be right: people, process, practices, and environment.