bosisler's shared items in Google Reader

The Search

(author unknown) — Thu, 17 Sep 2009 21:00:00 PDT

The Only Truly Failed Project

Jeff Atwood — Thu, 20 Aug 2009 00:59:59 PDT

Do you remember Microsoft Bob? If you do, you probably remember it as an intensely marketed but laughable failure -- what some call the "number one flop" at Microsoft.

There's no question that Microsoft Bob was nothing short of an unmitigated disaster. But that's the funny thing about failures -- they often lead to later successes. Take it from someone who lived and breathed the Bob project:

I was the one who sent Bill Gates email at the height of the positive Bob-mania that said we were likely to face a horrible backlash. Tech influentials had started telling me that they were going to bury Bob. They not only didn't like it, they were somehow angry that it had even been developed. It was personal.
And that's exactly what happened. Bob got killed. But first, it was ridiculed and stomped.
For Microsoft, it was a costly mistake. For the people who worked on it, Bob taught many lessons. Lessons that came into play for subsequent products that made a big impact, both at Microsoft and beyond.
How many people know that the lead developer for Bob 2.0 was also the co-founder of Valve and the development lead for Half-Life, which became an industry phenomenon, winning more than 50 Game of the Year awards and selling more than 10 million copies?
Or that Darrin Massena - development lead for Bob 1.0, most recently named Technical Innovator of the Year here in Washington State - and Valve co-founder Mike Harrington are the co-founders and partners behind Picnik - which is now the world's leading online photo editor, attracting almost 40 million visits a month and a million unique users a day.

And then, of course, I'd be remiss if I didn't mention that Melinda French -- Bill Gates' future wife -- managed the Microsoft Bob project at one point. Bob was the first Microsoft consumer project that Bill Gates personally had a hand in launching. Well, at least he got a wife out of it.

Yes, Bob was an obvious, undisputed and epic failure. We can point and laugh at Bob. But to me, Bob is less of a comic figure than a tragic one.

Unless you're an exceptionally lucky software developer, you've probably worked on more projects that failed than projects that succeeded. Failure is de rigeur in our industry. Odds are, you're working on a project that will fail right now. Oh sure, it may not seem like a failure yet. Maybe it'll fail in some completely unanticipated way. Heck, maybe your project will buck the odds and even succeed.

But I doubt it.

I own a boxed copy of Microsoft Bob. I keep it on my shelf to remind me that these kinds of relentless, inevitable failures aren't the crushing setbacks they often appear from the outside. On the contrary; I believe it's impossible to succeed without failing.

Charles Bosk, a sociologist at the University of Pennsylvania, once conducted a set of interviews with young doctors who had either resigned or been fired from neurosurgery-training programs, in an effort to figure out what separated the unsuccessful surgeons from their successful counterparts.
He concluded that, far more than technical skills or intelligence, what was necessary for success was the sort of attitude that Quest has -- a practical-minded obsession with the possibility and the consequences of failure. "When I interviewed the surgeons who were fired, I used to leave the interview shaking," Bosk said. "I would hear these horrible stories about what they did wrong, but the thing was that they didn't know that what they did was wrong. In my interviewing, I began to develop what I thought was an indicator of whether someone was going to be a good surgeon or not. It was a couple of simple questions: Have you ever made a mistake? And, if so, what was your worst mistake? The people who said, 'Gee, I haven't really had one,' or, 'I've had a couple of bad outcomes but they were due to things outside my control' -- invariably those were the worst candidates. And the residents who said, 'I make mistakes all the time. There was this horrible thing that happened just yesterday and here's what it was.' They were the best. They had the ability to rethink everything that they'd done and imagine how they might have done it differently."

I recently watched the documentary Tilt: The Battle to Save Pinball.

It's a gripping story of a pinball industry in crisis. In order to save it, the engineers at Williams -- the only remaining manufacturer of pinball machines in the United States -- were given a herculean task: invent a new form of pinball so compelling that it makes all previous pinball machines seem obsolete. I don't want to spoil the whole documentary, so I'll gloss over exactly how that happened, but astoundingly enough -- they succeeded.

And then were promptly laid off en masse, as Williams shut down its pinball operations.

Unlike Microsoft Bob, the Williams engineers built an almost revolutionary product that was both critically acclaimed and sold well -- but none of that mattered. It's sobering to watch the end reel of Tilt, as the engineers involved mournfully discuss the termination of their bold and seemingly successful project.

Everyone was in awe. They couldn't understand why it happened. Here we'd just done this thing that from all we could tell was a total success. Why would they do that?
We succeeded. Management gave us an impossible goal, and we sat there and we actually did what they thought we couldn't do.
You know, we didn't really win... we lost. I gave it everything I had. I think that those fifty guys that worked on it, they also passionately did everything that they could.

Sometimes, even when your project succeeds, you've failed. Due to forces entirely beyond your control. It's depressing, but it's reality.

The trailout isn't all doom and gloom. It also documents the ways in which these talented pinball engineers went on to practice their craft after being laid off. Most of them still work in the video game or pinball industry. Some freelance. Others formed their own companies. A few went on to work at Stern Pinball, which figured out how to make a small number of pinball machines and still turn a profit.

These two stories, these two projects -- the abject failure of Microsoft Bob, and the aborted success of Pinball 2000 -- have something in common beyond mere failure. All the engineers involved not only survived these failures, but often went on to greater success afterwards. Possibly as a direct result of their work on these "failures".

Failure is a wonderful teacher. But there's no need to seek out failure. It will find you. Whatever project you're working on, consider it an opportunity to learn and practice your craft. It's worth doing because, well, it's worth doing. The journey of the project should be its own reward, regardless of whatever happens to lie at the end of that journey.

The only truly failed project is the one where you didn't learn anything along the way.

[advertisement] Interested in agile? See how a world-leading software vendor is practicing agile.

Supported Features

(author unknown) — Tue, 04 Aug 2009 21:00:00 PDT

Ali Erkan İMREK: Bunu yapmak çok mu zordu? :D

(author unknown) — Mon, 20 Jul 2009 18:05:09 PDT

Bir disk bölümünü istediğim gibi bağlamayı beceremeyince gogıllamaya başladım, sırasıyla çeşitli siteleri açıyordum ve bir dağıtımın e-posta listesinde birden harika bir bağlantı gördüm, önce bağlantının harika olmasının nedeni üzerindeki "You are lucky, your solution is here..." yazısıydı ama sonra yaşadığım dumur daha harikaydı, size de yaşatmak isterim;

Your solution is here...

Bunu forumlarda sık sık kullanacağım sanırım :)

CNR

(author unknown) — Tue, 12 May 2009 21:00:00 PDT

Ali Erkan İMREK: Kamu Kurumları Artık Açık Standartlar Kullanmak Zorunda

(author unknown) — Tue, 21 Apr 2009 05:29:20 PDT

Bu aralar, ülkemizdeki Linux kullanıcılarının belki de en büyük sorunlarından birisi olan, internet ile sunulan kamu hizmetlerindeki IE-Windows zorunluluğu konusuna takmış durumdayım.

Önceki günlük girdisinde böyle yaygın bir sorunun Linux Şenliğinde de gündeme gelmesi gerektiğini yazmıştım ve "Hadi mevcut siteleri boşverin en azından yeni açılan hizmetlerde özgürlüğün sağlanması Başbakanlıktan yayınlanacak iki satırlık bir genelge ile de halledilebilir." demiştim. Böyle bir genelge kısa süre önce yayınlanmış;

Evet Başbakanlıktan yayınlanan 2009/4 sayılı genelge ile e-devlet projesi kapsamında düzenlenen "Birlikte Çalışabilirlik Esasları Rehberi"'nin artık kamu kurumlarının internet üzerinden vereceği hizmetlerdeki standartları belirleyeceği, mevcut hizmetlerin de bu rehbere uyumlu hale getirilmesi isteniyor. (Belge sürekli güncelleneceğinden doğrudan bağlantı vermedim)

Şu anda ikinci sürümü yayınlanmış olan belgedeki bazı ifadeler şöyle;

"Merkezi ve yerel düzeydeki tüm kamu kurum ve kuruluşları, bu Rehber’de yer alan esaslara uymakla yükümlüdür."

"Bilgi ve hizmetlerin web sayfası ve diğer alternatif kanallardan, kullanıcılar için tespit edilen arayüzlerin toplumun tüm fertleri tarafından kolay kullanılabilecek ve kullanıcı tarafında gerekli olabilecek ek ticari yazılımları mümkün olan en alt seviyede tutacak şekilde sunumu hedeflenmektedir."

"3.2.2 Ana İletişim Mekanizması Olarak İnternet ve www’in Kullanımı
Hedef, küresel İnternet devriminde maliyeti ve riski düşürebilmek, İnternet’in tüm taraflarca aktif olarak kullanımını sağlamaktır. Bu amaçla geliştirilecek uygulamaların arayüz olarak W3C standartlarını sağlayan İnternet tarayıcılarını (browser) desteklemesi esastır. Kullanıcı tarafından herhangi bir lisans ücreti gerektirmeyecek şekilde tarayıcı vasıtasıyla indirilebilen eklenti ve aracı yazılımlardan yararlanılabilir. "

"3.2.6 Açık Standartların ve Uluslararası Standartların Kullanımı

Birlikte çalışabilirliği mümkün kılma ve rekabeti artırma hedefi kapsamında açık standartların kullanımı benimsenmiştir..... " (Sonrasında açık standardın tanımı yapılıyor)

"Standartlar belirlenirken dikkat edilen temel noktalar; sunulan bilgilerin kullanıcı tarafında asgari derecede ek yazılım gerektirmesi, kullanılacak araçların mümkün olduğunca açık standartlara dayalı olması ve bu bilgilere farklı platformlardan ulaşılabilmesidir."

"Üzerinde işlem yapılabilmesine olanak sağlayan kelime işlem, sunum ve elektronik çizelge belgelerinin paylaşımı için aşağıdaki tabloda belirtilen formatlardan en az birinin kullanımı zorunludur. Bunlardan hangisinin kullanılacağına ihtiyaca göre karar verilebilir....." (Listede Microsoft'a ait sadece Microsoft Office 97 biçimi bulunuyor, sonraki sürümleri yok, tabii ki OpenOffice belgeleri var)

Uzun lafın kısası artık hiçbir kamu kurumu "Bu site sadece IE ile düzgün görüntülenir", "Bu site sadece IE ile çalışır" veya "Belgeleri açmak için MS Office 200x sürümü gereklidir" diyemeyecek, artık bu genelge gerekçe gösterilerek sitelerin Firefox ile çalışması ve belgelerin OpenOffice biçiminde yayınlanması talebinde bulunabileceğiz.

Hadi durmayın, Microsoft ürünleri kullanmadığınız için alamadığınız kamu hizmetleri için kurumlara baskı yapma zamanı.

Emrah Eryılmaz: Gerçek zamanlı (real-time) sistem nedir?

(author unknown) — Tue, 21 Apr 2009 01:13:00 PDT

İşlerini, tam zamanında yapan sisteme, gerçek zamanlı sistem denir. Dolayısı ile tam zamanında yapılması gereken işlerimiz yoksa, gerçek zamanlı bir sisteme de ihtiyacımız yok demektir.

Bir işin, tam zamanında yapılması gerekiyorsa bu iş, zaman açısından kritik bir iştir. Zaman açısından kritik işler, zamanında yapılamazlarsa başarısızlıkla sonuçlanmış olurlar.

Örneğin yemek pişirmek, zaman açısından kritik bir iştir. Bir yemek, olması gerekenden az veya çok pişirilirse, başarısızlıkla sonuçlanmış demektir. Dolayısı ile iyi aşçılar, gerçek zamanlı çalışan organik sistemlerdir.

Yalnız bu tanımda dikkat edilmesi gereken bir şey daha vardır. O da tam zamanında ifadesi ile kastedilen işin bitirilme anının, aslında akıp giden zaman içinde bir anı değil, bir süreyi ifade ettiğidir.

180°'de 45 dakika pişmesi gereken levrek buğulamayı, 44. dakikada veya 46. dakikada fırından çıkarırsak aslında hatalı birşey yapmış olmayız çünkü bu ufak sapma, kabul edilebilir düzeydedir ve kimse kalkıp da 'bu yemek iyi pişmemiş' demez. Eğer yemeği yapan, işinin ehli bir aşçı ise yemeğin, çiğ veya yanık şekilde önümüze gelmeyeceğini biliriz.

Gerçek zamanlı sistemler, latency terimi ile ifade edilen bu sapmaların, belli bir değerden küçük olacağını bize garanti ederler.

Soft Real-time ve Hard Real-time
Aşçı denilen organizmaların, yemeklerin pişirilme süreleri konusunda ne kadar hassas sistemler olduğuna değinmiştik. Peki ama aşçılar hiç mi hata yapmaz? Bir aşçı, arada bir hata yapıp yemeği hafif yaksa ne olur?

Ne olacağı, bu aşçının yemeklerini kimin yediğine bağlıdır. Eğer Sirkeci'de bir lokantada çalışıyorsa (ki burada kasdedilen Konyalı'nın aşçıları değildir) hafif yanık yemeği müşteriye kakalarsın gider, en kötü ihtimal o müşteri, bir daha lokantaya uğramaz. Yani çok da dert değil, müşterinin suyu mu çıktı? Bu gelmezse öbürü gelir.

Eğer söz konusu aşçımız, sarayın aşçıbaşısı ise ve yemeklerini yiyen padişah ise, işte o zaman durum kritiktir, hayati bir durum söz konusudur. Artık aşçıya reset mi atarlar, kazığa oturtup Youtube'da videosunu mu yayınlarlar bilemiyorum.

Birinci aşçı organizması, soft real-time sisteme; ikinci aşçı organizması, hard real-time sisteme örnektir.

İşlerimizi, belli bir sapmayı aşmayacak şekilde yapacağını bize garanti eden sistemimiz, arada sırada bu sözünü yerine getiremiyor ama bu kusurun, göz ardı edilebilir sonuçları oluyorsa, söz konusu sistem soft real-time'dır.

Sistemimiz, garanti edilen sapma aralığının asla ve asla dışına çıkmıyorsa ve bu sistemde çalışan işler, sapma aralığının dışına çıkıldığında kabul edilemez sonuçlar doğuruyorsa, sistemimiz hard real-time'dır.

Jitter
Aşçıların bir tipi vardır ki buna da jitter denir. Mutfak havalandırmasının iyi olmamasından dolayı sürekli buhar altında kalan ve yamaklığı sırasında her gün zorla üç çuval patates soydurulan aşçılar arasında sıklıkla bu tipe rastlanır. Jitter'lar yemeği, bazen az pişmiş bırakır, bazen hafiften yakarlar. Ama bazen de bakarsın en mükemmel yemekle çıkıp gelirler.

Bu tip aşçılar lokanta sahipleri tarafından pek sevilmez ve istenmezler çünkü müşteriyi kaçırırlar. Yemeği hep pişkin yapsa sorun değil, o zaman en azından pişkin yemek seven müşteriler sürekli gelir. Sürekli az pişmiş bıraksa da sorun değil, o zaman da az pişmiş yemek seven müşterilerle idare edilir. Mutfaktan ne çıkacağı belli olmayınca, müşterinin hiçbir türü kalmaz.

Bu nedenle gerçek zamanlı sistemlerde jitter sevilmez. Sapma olacaksa bile (ki mutlaka olur, bu sadece ne kadar hassas ölçüm yaptığımıza bağlıdır) en azından sapmaların hep aynı yönde ve benzer oranlarda olması istenir; tabii garanti edilen aralığı da aşmamak koşulu ile...

Gerçek zamanlı sistem hızlı mı olmalı?
Aşçımız, evde çocuklarına yemek pişiren bir anne ise hızlı olmasına gerek yoktur, üç tencereyi kontrol altında tutabilmesi yeterlidir. Ama onlarca yemeğin aynı anda hazırlanması gereken bir lokanta söz konusu ise bunca yemeği aynı anda kontrol edebilecek ve hepsinin tam kıvamında pişmesini sağlayabilecek hızlı bir aşçıya ihtiyaç vardır.

Tabii aşçının hızlı olması, yemekleri tam kıvamında pişireceğinin garantisi değildir. Ama aynı zamanda, beş kap yemeği tam kıvamında pişirebilen bir aşçının, yeterince hızlı değilse on kap yemeği tam kıvamında pişireceği de garanti değildir.

Gerçek zamanlı sistemler, kaldırabileceği oranda iş yükleri varsa gerçek zamanlı olma özelliklerini koruyabilirler. Dolayısı ile gerçek zamanlı bir sistem kurgulanırken iş yükü, baştan kesin bir doğrulukla hesaplanmalıdır.

Gerçek zamanlı sistemde tampon (buffer) kullanımı
Börekçiler tampon ile çalışır. Bi sabah börekçiye gidip 'peynirli var mı' diye sorulduğunda '10 dakika sonra hazır' cevabı alınabilirken, ertesi gün tezgahın üzerinde tonlarca peynirli börek bulunabilir. Dolayısı ile 'bugün kesin peynirli börek yiyecem' diye börekçiye gidip oturduğumuzda böreğin ne zaman önünüze geleceğinden asla emin olamayız. Bu nedenle hard real-time sistemlerde tampon kullanılmaz.

Pre-emptive nedir?
Aile terbiyesi almamış aşçıya, pre-emptive denir. Bu aşçı tipi, yemeklerine özen göstermez, kimini yakar, kimini çiğ bırakır. Yemek diye çiğ tavuk sunduğu bile görülmüştür ama ne zaman ki kapıdan yağlı bir müşteri girer, hemen Oktay Usta kesilir. Bu müşterinin yemeklerine özel bir hassasiyet gösterir, mükemmel olması için gayret eder. Tabii bu tip bir aşçı bozuntusunun ne derece mükemmel(!) iş yapacağı malumunuz. O nedenle hard real-time dünyasında yeri yoktur, adam yerine konulmaz.

Bu yazıdan çıkarılacak sonuca gelirsek, son söz olarak şunu diyebiliriz: 'Hamburger yemeyin'

Serkan Kaba: Evince ile özgür PDFler

(author unknown) — Fri, 17 Apr 2009 12:16:18 PDT

Geçenlerde elime yazdırma korumalı bir PDF geçti. O an elimde sadece Acrobat Reader olduğu için yazdırma imkanım olmadı. Ancak GNOME masaüstünde kullandığım Evince’in bunu bir şekilde aşabileceği düşüncesi oluştu. Ne de olsa ekrana gösteriyorsa yazdırabilirdi de. Evince kaynak kodunu incelerken bunun /apps/evince/override_restrictions anahtarıyla kontrol edildiğini farkettim. Üstüne üstük bu anahtarın varsayılan değeri true idi. Bunun düşünülmüş olmasına şaşırmadan PDFyi açtım ve dosyaya yazdır seçeneği ile yeniden kısıtsız PDF olarak oluşturdum. Bu adımdan sonra oluşan PDFyi Acrobat Reader ile yazdırabildim. Eğer bu ayar dağıtımınızda varsayılan olarak true değilse ekrandaki gibi değiştirebilirsiniz.

Posted in gezegen, linux, pdf

Zemberek NLP: Zemberek Ubuntu paketleri hazırlandı

(author unknown) — Wed, 08 Apr 2009 05:47:30 PDT

Daha önceki yazımda Rail ALİEV'in Ubuntu paketlerinin hazırlanmasına yönelik çalıştığından bahsetmiştim. Evet, çalışmaları meyvelerini verdi ve kütüphane, sunucu, zpspell (Zemberek KDE3 eklentisi için gerekli program) Openoffice.org ve Firefox eklentileri için hazırlanan paketler kendisinin kişisel paket arşivinde (PPA) yerini aldı. Bağlantıda yer alan depo adreslerini kullanarak paketleri kurup kullanmaya başlayabilirsiniz.

The Hardest Interview Puzzle Question Ever

Jeff Atwood — Tue, 17 Mar 2009 00:59:59 PDT

Have you ever been to an interview for a programming job where they asked you one of those interview puzzle questions? I have. The one I got was:

How much of your favorite brand of soda is consumed in this state?

And no, the correct answer is not who cares, unless the thing you don't care about is getting the job you're interviewing for. I didn't know it at the time, but this is a Fermi Question. (To prevent spoilers, the answer can be found in a previous blog post.)

Puzzle questions were all the rage in programming interviews in the 90s and early aughts. This is documented in the book How Would You Move Mount Fuji? with a specific emphasis on Microsoft's hiring practices.

It is prudent to study common interview puzzle questions if you know you'll be interviewing at a company that asks these sorts of questions. And if you think you're ace at programming puzzle questions, then I challenge you to point your massive brain at this, the hardest interview puzzle question ever:

A hundred prisoners are each locked in a room with three pirates, one of whom will walk the plank in the morning. Each prisoner has 10 bottles of wine, one of which has been poisoned; and each pirate has 12 coins, one of which is counterfeit and weighs either more or less than a genuine coin. In the room is a single switch, which the prisoner may either leave as it is, or flip. Before being led into the rooms, the prisoners are all made to wear either a red hat or a blue hat; they can see all the other prisoners' hats, but not their own. Meanwhile, a six-digit prime number of monkeys multiply until their digits reverse, then all have to get across a river using a canoe that can hold at most two monkeys at a time. But half the monkeys always lie and the other half always tell the truth. Given that the Nth prisoner knows that one of the monkeys doesn't know that a pirate doesn't know the product of two numbers between 1 and 100 without knowing that the N+1th prisoner has flipped the switch in his room or not after having determined which bottle of wine was poisoned and what color his hat is, what is the solution to this puzzle?

In other words, I hate puzzle questions.*

I'm also not a huge fan of those abstract impossible questions, eg, "how many optometrists are there in Seattle?", but I suppose that's a matter of taste. If you absolutely must, at least ask an impossible question that has some relevance to a problem your very real customers might encounter. I just can't muster any enthusiasm for completely random arbitrary puzzles in the face of so many actual, real world problems.

And yes, I totally failed that interview. Which was disappointing, because it was kind of a cool job.

Not that my proposal for interviewing programmers was any more popular, though I do think it's much better.

I have my own theory about the ideal way to interview developers: have the candidate give a 10 minute watercooler presentation to your team on something they've worked on. I think this is a far better indicator of success than a traditional interview. You'll quickly ascertain:

Is this person passionate about what they are doing?
Can they communicate effectively to a small group?
Do they have a good handle on their area of expertise?
Would your team enjoy working with this person?

You'd certainly want to complement this type of interview with some actual hands on programming, to make sure the applicant isn't full of crap -- although I'm pretty sure that you can't B.S. your way through a technical presentation to a handful of your peers if you truly have no idea what you're talking about. (And if you can, you should be CEO of a startup by now.)

What I'm optimizing for here is the ability to communicate. Most programmers, once they pass the FizzBuzz level of competency, are decent enough. But coding chops aren't enough. To go from good to great, you must be able to communicate effectively: with your teammates, your manager, the users, and ultimately the world.

My wife and I just finished a five day hospital stay for the birth of our first child. During our stay, we were assisted by a parade of different nurses, at least two different nurses every day, sometimes more as we progressed to different areas of the hospital and through daily shift changes. The quality of care at this particular hospital is generally quite high, but we were flummoxed by the disparity in care between the worst nurses and the best nurses. After a few days, I finally figured out the common characteristic -- the worst nurses were invariably the worst communicators! The fact that these nurses couldn't effectively communicate with us:

why they needed to do something
what the options were
offer advice
troubleshoot our problems

Meant they ended up feeling like rigid, inflexible proceduralists who didn't care or constantly had to appeal to authority. Of course, this wasn't true. I'm sure they were perfectly competent registered nurses. But in the absence of reasonable communication, it sure seemed that way. To be fair, these nurses were frequently (but not always!) non-native English speakers.

Hiring is difficult under the best of conditions. But an interview process that relies too heavily on puzzle questions is risky. Sure, you may end up with programmers who can solve (or memorize, I guess) the absolute gnarliest puzzle questions you throw at them. But isn't effectively communicating those solutions to the rest of the team important, too? For many programmers, that's the hardest part of the puzzle.

* although I expect aficionados of the style should be able to identify all the classic interview puzzle questions represented here.

[advertisement] Improve Your Source Code Management using Atlassian Fisheye - Monitor. Search. Share. Analyze. Try it for free!

On the spectrial

Joaquin Jares — Tue, 24 Feb 2009 05:09:28 PST

Last week started the spectrial, a trial between some international movie, music and tv producers and The Pirate Bay. In case you've been living under a rock for the past few years, The Pirate Bay is one of the biggest torrent trackers in the world, run in Sweden by a number of people. The spectrial (so called by TPB members) was announced more than a year ago, and now it's here. The folks at TPB want to make it as public as possible. The producers are used to making this trials very secret and introducing all sort of semi-truths and outrageous lies. They won't be able to if too many people are watching.

First let's take something out of the way: I'm absolutely on the side of TPB in this trial. That doesn't make me an anti-copyright zealot. I think producers have a right to enforce their copyright. But this is much more than that. The trial on TPB is not about copyright, it's about technology. Many people around the world are seeing that TPB is winning, and they think this is a great news for anti-copyright movements. Let me tell you, it's not. If TPB wins, nothing will happen. No international laws will change and the ruling will probably be appealed. If TPB loses the site will not go down. It'll get moved to a place where this trial hasn't set a legal precedent (as a matter of fact, it already is). But the blow on technology will be great.

Content providers have a right to enforce their copyright, but they think they have much more than that: they think they can dictate which technology is good and which technology is bad. In this case, they think that anything related to torrents is bad. And they want to ban it. No private company with partial and focused interest should be able to do that. It's as if horse raisers many years ago when the car was first introduced could have said "cars may be a danger to the horses we sell, we should get to dictate which car is ok" and then imposing all sorts of artificial limitations on what cars can do not to make the public safe but to make their business safe.

They did it before, also: your dvd has a "region code", which is an artificial limitation on where you can use your dvd because it affects the content provider's business. And the fact that the region code is enforced is not a business contract between hardware producers and content providers, it's the law. If this were a business contract, money will exchange hands. As it is the law, hardware providers all over the world are forced to do it with no compensation. And if you try to bypass it (as you should, since you legally bought both the dvd and the dvd player) you're also a criminal (in the US at least) thanks to the DMCA. And that's not the only case. You might have heard of Spore's DRM. Limiting what a legal owner can do while not stopping piracy at all. Or the infamous betamax (Sony vs Universal) trials where content producers wanted to stop you from getting a video recorder because you could potentially pirate their content.

They have a right to enforce their copyright, they don't have the right to state that a technology capable of violating their copyright must be illegal. At some point in time, they will find out that the internet can help violate their copyright and they'll try to ban the internet. It's not like they're not trying.

What I really don’t get is why the recording industry is not seizing this opportunity. The distributors may be at risk (partially) since distributing is now close to free. But the recording industry should be benefiting from this reduced cost. And benefiting for worldwide reach without international contracts. And benefiting for millions of extra eyes. And benefiting from social networking and the new fans they can get out of that. But they aren’t. Instead, they’re treating their fans as thieves. Just watch the academy awards, where they were proud of a very big wall they put in place to avoid outside people from watching what was happening in the red carpet. Got that? You’re a fan, you love a show/director/actor/whatever. You go to the ceremony just to catch a glimpse of one of these guys, and they love you so much that they put a wall there so you can’t.

That’s what the producers think of their fans lately. There is a barrier today between established producers and their fans. The fans are trying to tear it down. The producers are building a higher wall. That just doesn’t add up. And as soon as a quality content producer with quality content comes up and tears the wall the fans will go to him. There’s no doubt about that.

If I had a say, I’ll follow two very simple rules:

1) Don’t charge for something that can be had for free, either legally or illegally. When your fans can download your music/movies/etc for free and you’re charging over $40 dollars for the same content with no added benefit, they feel cheated. You know there’s other ways to make money out of the content. You’ve been doing it on TV for as long as I’ve been alive.

2) Don’t be greedy. These other ways to make money come with an added cost: they may hinder the artistic quality of your content, turning it into more business than art. Don’t do that. You’ll loose your audience, and that’s not good business.

I don’t get why content providers are not doing this, specially TV content providers. Is it that hard to place a few ads on top of the action in Prison Break, in a non-invasive way, and charge private companies for them while knowing that the series will be seen by millions of people because it’s freely available on the internet? Is it that hard to place ads that people will actually enjoy at certain points in the show, in a non-invasive way, etc etc? I simply don’t get it.

And then there’s the issue of statistics and previewing. Content on internet is very easy to publish, and it gives a lot of good feedback. Content on TV/theaters is far more complex and it doesn’t provide good feedback. Imagine a world where the content gets to the internet first, gets “prescreened” by true fans, and then goes to the regular media where lots of people will also watch it, but you already know which content had a bigger audience and you can plan accordingly.

TV is not going away anytime soon. I know producers think it is, and that worries them. We have the WGA strike from last year to prove it. But we still have a lot of good TV years. The internet is not that accessible for the average user and it’s transmission quality is yet not on par with cable TV. We technical folks do not yet have a clue on how to make it accessible for the average user. That’s the content producers’ head start. But they are not getting it. Instead, they try to turn the internet to a TV. But the internet is not (and hopefully will never be) like the TV. The internet is like a high quality video phone. The TV allows a monologue from the producers to the viewers. The internet is a dialogue. Producers should be benefitting from this dialogue.

So in conclusion, producers may be able to win this trial (although it doesn’t look like that right now), but they won’t be defending anything. I sincerely hope TPB wins, but not because of copyright. I just want the studios to wake up, and this trial may help. The betamax trial did help. The future lives in these sharing systems and sooner or later someone will notice. And when they do, producers will tell them “there’s no way that someone that’s not us can provide a quality product”. But someone will. And when he does, producers will be dead. Hopefully they realize that this is inevitable before it happens. And then copyright will die, and then we will have our flying cars and live in the future (at least in the future of media distribution).

The Bad Apple: Group Poison

Jeff Atwood — Thu, 19 Feb 2009 23:59:59 PST

A recent episode of This American Life interviewed Will Felps, a professor who conducted a sociological experiment demonstrating the surprisingly powerful effect of bad apples.

Groups of four college students were organized into teams and given a task to complete some basic management decisions in 45 minutes. To motivate the teams, they're told that whichever team performs best will be awarded $100 per person. What they don't know, however, is that in some of the groups, the fourth member of their team isn't a student. He's an actor hired to play a bad apple, one of these personality types:

The Depressive Pessimist will complain that the task that they're doing isn't enjoyable, and make statements doubting the group's ability to succeed.
The Jerk will say that other people's ideas are not adequate, but will offer no alternatives himself. He'll say "you guys need to listen to the expert: me."
The Slacker will say "whatever", and "I really don't care."

The conventional wisdom in the research on this sort of thing is that none of this should have had much effect on the group at all. Groups are powerful. Group dynamics are powerful. And so groups dominate individuals, not the other way around. There's tons of research, going back decades, demonstrating that people conform to group values and norms.

But Will found the opposite.

Invariably, groups that had the bad apple would perform worse. And this despite the fact that were people in some groups that were very talented, very smart, very likeable. Felps found that the bad apple's behavior had a profound effect -- groups with bad apples performed 30 to 40 percent worse than other groups. On teams with the bad apple, people would argue and fight, they didn't share relevant information, they communicated less.

Even worse, other team members began to take on the bad apple's characteristics. When the bad apple was a jerk, other team members would begin acting like a jerk. When he was a slacker, they began to slack, too. And they wouldn't act this way just in response to the bad apple. They'd act this way to each other, in sort of a spillover effect.

What they found, in short, is that the worst team member is the best predictor of how any team performs. It doesn't seem to matter how great the best member is, or what the average member of the group is like. It all comes down to what your worst team member is like. The teams with the worst person performed the poorest.

The actual text of the study (pdf) is available if you're interested. However, I highly recommend listening to the first 11 minutes of the This American Life show. It's a fascinating, highly compelling recap of the study results. I've summarized, but I can't really do it justice without transcribing it all here.

Ira Glass, the host of This American Life, found Felps' results so striking that he began to question his own teamwork:

I've really been struck at how common bad apples are. Truthfully, I've been kind of haunted by my conversation with Will Felps. Hearing about his research, you realize just how easy it is to poison any group [...] each of us have had moments this week where we wonder if we, unwittingly, have become the bad apples in our group.

As always, self-awareness is the first step. If you can't tell who the bad apple is in your group, it might be you. Consider your own behavior on your own team -- are you slipping into any of these negative bad apple behavior patterns, even in a small way?

But there was a solitary glimmer of hope in the study, one particular group that bucked the trend:

There was one group that performed really well, despite the bad apple. There was just one guy, who was a particularly good leader. And what he would do is ask questions, he would engage all the team members, and diffuse conflicts. I found out later that he's actually the son of a diplomat. His father is a diplomat from some South American country. He had this amazing diplomatic ability to diffuse the conflict that normally would emerge when our actor, Nick, would display all this jerk behavior.

This apparently led Will to his next research project: can a group leader change the dynamics and performance of a group by going around and asking questions, soliciting everyone's opinions, and making sure everyone is heard?

While it's depressing to learn that a group can be so powerfully affected by the worst tendencies of a single member, it's heartening to know that a skilled leader, if you're lucky enough to have one, can intervene and potentially control the situation.

Still, the obvious solution is to address the problem at its source: get rid of the bad apple.

Even if it's you.

[advertisement] Tired of restoring deleted files? Get PA File Sight and track down the culprit. PA File Sight – file auditing made easy. Download the Free Trial!

And this one is Google’s Smart Ad!

esokullu — Sat, 30 Jun 2007 19:25:27 PDT

Saw this by chance while reading a nice article on Google Operating System Blog. Reminds me the PHP job ad of Grou.ps.

Very smart. Click the image to see how it looked like on the page. Steals my heart

Olgun (ve dolgun) geliştirici...

(author unknown) — Mon, 21 Apr 2008 06:01:00 PDT

Bahar ayları geldiği zaman hem üniversite öğrencilerini hem de yazılım şirketlerini bir telaş alıyor. Yeni mezun olacak olan arkadaşlar içinden elbet bir bölümü daha yaz bitmeden bir iş yerinde işe girmiş oluyorlar. Dolayısı ile yaz ayları ve sonbahar aylarında da staj sonrasındaki ilk gerçek iş deneyimi ile yüzleşen genç arkadaşlarımızı görüyoruz. ODTÜ Teknokent'de bu çok daha kolay fark ediliyor. Sabah saat 9:00 sularında mesaiye gelenler arasında yepyeni yüzler görüyorsunuz.

Bu arkadaşlarımız meslek yaşamlarına ilk başlarken elbette okulda çeşitli nedenlerden öğretilemeyen şeyleri öğrenmek zorunda kalıyorlar. Mesela okulda aynı anda bir çok ders aldıkları için uzun süreli ve kalabalık ekip çalışmalarına giremiyorlar. Belki bir istisna olarak TOBB ETÜ'nün Ortak Eğitim Programı'nı gösterebiliriz. O konuda bu yıl biz de deneyim yaşayacağız, daha sonra aktarırım herhalde. Ama uzun lafın kısası, genç geliştiricilerin olgunlaşması - ve tipik olarak kilo alıp dolgunlaşması - süreci yaz aylarında başlıyor.

Peki bu süreç içinde genç arkadaşların neler öğrenmeye hazır olması gerekir. Yada 3-4 yıl deneyimli bir uygulama geliştirici ile yeni mezun birini ayıran neler vardır? Belli teknolojilerin (örneğin AJAX yada JBOSS Seam) bilinmesini kenara koyarsak esasında ne bilindiğinden çok o bilginin nasıl kullanıldığı üzerine farklar görüyoruz. Yani olgun geliştirici ne biliyorumdan çok nasıl yaparım (İng. know-how) üzerinde deneyime sahip. Bu deneyim farkının da odaklandığı bazı kritik işler yada süreçler olması kaçınılmaz. Peki bunlar nelerdir? Uzunca süredir aklıma gelenleri bir yazayım diyordum, şu ana denk geldi.

Şimdi düşünelim. Aklımıza neler gelecek.

Olgun uygulama geliştiriciler, projelerin daha uzun sürdüğünü bildikleri için uzun dönemli bir bakış açısı geliştiriyorlar. Bu da onların geçmişte arkalarında bıraktıkları işlerin ileride başlarına bela olmaması için farklı tür çalışmalarına neden oluyor. İşin ilginç yanı, bu yaklaşım daha nitelikli yani daha kaliteli iş çıkmasına neden olduğu gibi bazen işlerin daha çabuk bitmesini de sağlıyor. Bu yaklaşım hemen her şeye yansıyor.
Olgun geliştiriciler hemen her konuda disiplinli oluyorlar. Bu da tabii ki bir öz disiplin ve genelde kendi kendilerine koydukları kişisel kurallardan oluşuyor. Bu kuralar çalıştıkları iş yerlerinde uygulanan yazılı kurallar olsun olmasın genel anlamda yararlı şeyler. Zaman zaman kendi kurallarının ihlal edilmesi istenince ("aman abi bugünlük uyduruk bir şey teslim edelim" lafı gelince) itiraz etmekten de çekinmiyorlar. Çünkü kendi içlerinde biliyorlar ki, bu kurallar onların kendi iyilikleri için kendi koydukları kurallar.
Olgun geliştiricilerin yazdıkları kodlarla ilgili disiplinleri onların kodlama stilleri kadar çalışma ortamlarına da yansıyor. Neyin nasıl kurulduğu ve nasıl kullanıldığı çok da iyi anlaşılmayan araçlardan oluşan kümeler yerine temiz görünümlü, aralarındaki ilişki iyi tanımlanmış araçlar kullanıyorlar. Bu ille de belli bir firmanın araçlarına saplanmak demek değil. Hatta bir çok defa özgür yazılım araçlar yada kendi ihtiyaçları için kendi yazıp geliştirdikleri ve çevreleri ile paylaştıkları araçları da içeriyor.
Olgun geliştiriciler, yazdıkları kodların temiz, kolay anlaşılabilir arayüzlere sahip olmasına özen gösteriyorlar. Gerektiği zaman kendi kodlarını bu amaçla yeniden yapılandırmaktan da kaçınmıyorlar. Aynı şekilde kodun sınanması yani test edilmesi için gerekli yaklaşımları kullanmayı ihmal etmiyorlar. Özellikle testlerin eksiksiz ve hatasız olduğuna dikkat ediyorlar. Test verilerini ilk baştan talep ediyorlar.
Olgun geliştiriciler kodlarını yönetmek için CVS yada SVN gibi bir aracı kullanırken de bazı farklar gösteriyorlar. Özellikle ilk dikkat çeken şey, yaptıkları katkıların (İng. commit) açıklama notlarını girmeleri ve bunları da uzun uzun yazmaları. Ayrıca bu notlarda yazım hatalarından kaçınmaları da önemli. Çünkü hata ayıklamaya çalıştığınızda, belli bir değişikliğin ne zaman yapıldığını aramaya kalkarsanız içinde bir kaç bin katkı bulunan bir SVN deposunda arama yapmanız gerekecektir. Katkıların açıklamalarının yazılması bu işi inanılmaz hızlandırabiliyor.
Olgun geliştiricilerin bir diğer çok önemli özelliği de yaptıkları işi yazmaları. Bu sadece haftalık rapor şeklinde olmak zorunda değil; özellikle kodlama yada bir sistem yapılandırma gibi karmaşık işlerini kesinlikle belgeler ile anlatıyorlar. Bir çok yazılımın kaçınılmaz biçimde çevreden aldıkları parametreler ile çalışacağını (örneğin bir Java uygulaması için dahi çok dil desteği için .properties dosyalarına erişmek yapılandırmaya hasas biçimde bağlı) düşünürsek, bu önemli bir şey. Bu sayede hem kendileri eski projelere geri döndüklerinde, hem yeni kişilere eldeki projeyi anlatırlarken kolaylık yaşıyorlar.
Olgun geliştiriciler, sürekli olarak bir şey öğrenmek zorunda olduklarının bilincindeler ve çalışmalarını da buna göre yapılandırıyorlar. Hangi projede çalışırlarsa çalışsınlar, hangi aracı kullanırlarsa kullansınlar bu değişmiyor. Hem kendi öğrencikleri şeyleri belgelemeleri, hem de bunu insanlarla tartışarak bilgiyi iyice sinfirme çabaları ile dikkat çekiyorlar. Bir konudaki teknik bir sorunu araştırdığınızda, olgunlaşmış, kıdem kazanmış bir geliştiricinin bloguna denk geldiğiniz zaman aslında onun kendi çalışma defterine de denk gelmiş oluyorsunuz.
Olgun geliştiriciler, hem geliştirme hem öğrenme süreçlerinde daha sabırlı. Bu sadece yaşla ilgili bir şey de değil. Genel olarak daha yaşlı kişilerin daha sabırlı olduğunu görebilirken, uygulama geliştiricilere baktığımızda resim oldukça farklı olabiliyor. Özellikle olgun geliştiriciler daha sabırlı. Aslında bu bir ikilemi de barındırıyor. Olgun geliştiriciler daha verimli çalıştıkları için daha çabuk sonuç alıyorlar. Ama bu onları gelirgin bir şekilde daha atılgan yada sabırsız yapmıyor. Bununla birlikte belli yaşı görmüş ama çalışma tarzı itibarı ile olgunlaşmamış bir çok kişi de son derece sabırsız biçimde çalışıyor. Belki de sabır ve disiplinli çalışma arasında bir bağlantı vardır.
Sabrın yanı sıra, olgun geliştiriciler aynı zamanda insan ilişkileri ve iletişim konusunda da belli beceriler geliştirmiş oluyor. Geyik muhabbeti yapacakları zaman yapıyorlar ama konu iş olduğu zaman iletişimi verimli tutacak bir yaklaşım belirliyorlar. Sorun tespit etmek ve çözüme doğru ilerlemek amaçlarından kopmayan, odaklı ve verimli bir iletişim tavırları var. Bu tavrın bazı nitelikleri kişiden kişiye değişse dahi, özü aynı kalıyor.
Olgun geliştiriciler, yaptıkları işin boyutlarını ve ne kadar sürede yapabileceklerini daha iyi tahmin ediyorlar. Bu elbette ki daha önceden bir çok benzer-benzemez proje yapmaktan ve teslim etmekten kaynaklanıyor. Ama bundan daha önemlisi, olgun geliştiriciler ilk tahminlerini zaman içinde güncelliyorlar. Dolayısı ile aylar önceden yapılmış bir tahmin yerine yakın zamanda güncellenmiş bir tahmin üzerinden hareket ediyorlar. Bu onların kısa dönemli planlarını daha iyi yapmalarını sağlıyor. Henüz olgunlaşmamış geliştiriciler ise ya hiç tahmin ve plan yapmıyor yada çok önceden, henüz eksik bilgi ile yaptıkları tahmin ve planların geçerli olduğunu sanıyorlar.

Bunların dışında akla gelecek şeyler elbette olacaktır. Ama benim ilk aşamada düşünebildikleirm bunlar. Sadece yeni mezun arkadaşlar değil, istediğimiz kadar deneyimli olalım, bu saydığım noktalarda kendimizi geliştirmek için hepimizin daha çok potansiyele sahip olduğumuzu düşünüyorum.

Yine önemli bir düşünce geliştirme noktası da özgür yazılım projeleri ile bireysel olgunlaşma arasındaki ilişki olabilir. Bu iki kavram arasında doğrudan yada dolaylı ilişkilerin saptanması ciddi bir konu olur herhalde.

Şapkayı önümüze koyacak olursak, biz Portakal Teknoloji'de ne kadar olgunuz yada ne şekilde olgunlaşıyoruz sorusunu da sormalıyız ve kendimizce yanıtlamalıyız.

Bakalım ileride bu konuya tekrar değinirsem, kesinlikle bir şeyler daha eklerim.

ASCII Pronunciation Rules for Programmers

Jeff Atwood — Thu, 12 Jun 2008 05:05:08 PDT

As programmers, we deal with a lot of unusual keyboard characters that typical users rarely need to type, much less think about:

$ # % {} * [] ~ & <>

Even the characters that are fairly regularly used in everyday writing -- such as the humble dash, parens, period, and question mark -- have radically different meaning in programming languages.

This is all well and good, but you'll eventually have to read code out loud to another developer for some reason. And then you're in an awkward position, indeed.

How do you pronounce these unusual ASCII characters?

We all do it, but we don't necessarily think much about the words we choose. I certainly hadn't thought much about this until yesterday, when I read the following comment left on Exploring Wide Finder:

A friend sent me a Java code fragment in which he looped through printing "Thank You!" a million times (it was a response to a professor who had extended the deadline on a paper). I responded with a single line of Ruby to do the same, and a single line of Lisp.
He wrote back: "Underscores, pipes, octothorpes, curly braces -- sheesh... I'll take a mild dose of verbosity if means I don't have to code something that looks like it's been zipped already!"

What the heck is an octothorpe? I know this as the pound key, but that turns out to be a US-centric word; most other cultures know it as the hash key.

I'm often surprised to hear what other programmers name their ASCII characters. Not that the words I personally use to identify my ASCII characters are any more correct, but there's far more variability than you'd expect considering the rigid, highly literal mindset of most programmers.

Perhaps that's why I was so excited to discover the ASCII entry in The New Hacker's Dictionary, which Phil Glockner turned me on to. It's a fairly exhaustive catalog of the common names, rare names, and occasionally downright weird names that programmers associate with the ASCII characters sprinkled throughout their code.

How many of these ASCII pronunciations do you recognize? Which ones are the "correct" ones in your shop?

Common Names

Rare Names

exclamation mark
bang
pling
excl
not
shriek

factorial
exclam
smash
cuss
boing
yell

wow
hey
wham
eureka
spark-spot
soldier
control

quotation marks
quote
double quote

literal mark
double-glitch
dieresis
dirk

rabbit-ears
double prime

hash
pound sign
number sign
pound

sharp
crunch
hex
mesh

grid
crosshatch
octothorpe
flash
square
pig-pen

tictactoe
scratchmark
thud
thump
splat

dollar sign
dollar

currency symbol
buck
cash
string

escape
ding
cache
big money

percent sign
mod
grapes

double-oh-seven

ampersand
amp
amper
and
and sign

address
reference
andpersand
bitand
background
pretzel

apostrophe
single quote
quote

prime
glitch
tick
irk

pop
spark
closing single quotation mark
acute accent

( )

opening / closing parenthesis
left / right paren
left / right parenthesis
left / right
open / close
open / close paren
paren / thesis

so/already
lparen/rparen
opening/closing parenthesis
opening/closing round bracket
left/right round bracket
wax/wane
parenthisey/unparenthisey
left/right ear

[ ]

opening / closing bracket
left / right bracket
left / right square bracket
bracket / unbracket

square / unsquare
u turn / u turn back

{ }

opening / closing brace
open / close brace
left / right brace
left / right squiggly
left / right squiggly bracket/brace
left / right curly bracket/brace

brace / unbrace
curly / uncurly
leftit / rytit
left / right squirrelly
embrace / bracelet

< >

less / greater than
bra / ket
left / right angle
left / right angle bracket
left / right broket

from / into (or towards)
read from / write to
suck / blow
comes-from / gozinta
in / out
crunch / zap
tic / tac
angle / right angle

asterisk
star
splat

wildcard
gear
dingle
mult
spider

aster
times
twinkle
glob
Nathan Hale

plus
add

cross
intersection

comma

cedilla
tail

dash
hyphen
minus

worm
option
dak
bithorpe

period
dot
point
decimal point

radix point
full stop
spot

slash
stroke
slant
forward slash

diagonal
solidus
over
slak
virgule
slat

backslash
hack
whack
escape
reverse slash

slosh
backslant
backwhack

bash
reverse slant
reversed virgule
backslat

colon

dots
two-spot

;

semicolon
semi

weenie
hybrid
pit-thwong

equals
gets
takes

quadrathorpe
half-mesh

question mark
query
ques

quiz
whatmark
what
wildchar

huh
hook
buttonhook
hunchback

at sign
at
strudel

each
vortex
whorl
whirlpool
cyclone

snail
ape
cat
rose
cabbage
commercial at

circumflex
caret
hat
control
uparrow

xor sign
chevron
shark (or shark-fin)
to the
fang
pointer

underline
underscore
underbar
under

score
backarrow
skid
flatworm

grave accent
backquote
left quote
left single quote
open quote
grave

backprime
backspark
unapostrophe
birk
blugle

back tick
back glitch
push
opening single quote
quasiquote

bar
or
or-bar
v-bar
pipe
vertical bar

vertical line
gozinta
thru
pipesinta
spike

tilde
squiggle
twiddle
not

approx
wiggle
swung dash
enyay
sqiggle (sic)

If you're curious about the derivation of some of the odder names here, there are an extensive set of footnotes (and even more possible pronunciations) at the ascii-table.com pronunciation guide.

So the next time a programmer walks up to you and says, "oh, it's easy! Just type wax bang at hash buck grapes circumflex and splat wane", you'll know what they mean.

Maybe.

[advertisement] Peer code review without meetings, paperwork, or stopwatches? No wonder Code Collaborator won the Jolt Award.

Investing in a Quality Programming Chair

Jeff Atwood — Sat, 05 Jul 2008 00:59:59 PDT

In A Developer's Second Most Important Asset, I described how buying a quality chair may be one of the smartest investments you can make as a software developer.

In fact, after browsing chairs for the last few years of my career, I've come to one conclusion: you can't expect to get a decent chair for less than $500. If you are spending less than that on seating -- unless you are getting the deal of the century on dot-bomb bankruptcy auctions -- you're probably making a mistake.

I still believe this to be true, and I urge any programmers reading this to seriously consider the value of what you're sitting in while you're on the job. In our profession, seating matters:

Chairs are a primary part of the programming experience. Eight hours a day, every day, for the rest of your working life -- you're sitting in one. Like it or not, whatever you're sitting in has a measurable impact on your work experience.
Cheap chairs suck. Maybe I've become spoiled, but I have yet to sit in a single good, cheap chair. In my experience, the difference between the really great chairs and the cheap stuff is enormous. A quality chair is so comfortable and accommodating it effortlessly melts into the background, so you can focus on your work. A cheesy, cheap chair constantly reminds you how many hours of work you have left.
Chairs last. As I write this, I'm still sitting my original Aeron chair, which I purchased in 1998. I can't think of any other piece of equipment I use in my job that has lasted me ten full years and beyond. While the initial sticker shock of a quality chair may turn you off, try to mentally amortize that cost across the next ten years or more.

Choice of seating is as fundamental and constant as it gets in a programming career otherwise marked by relentless change. They are long term investments. Why not take the same care and consideration in selecting a chair as you would with the other strategic directions that you'll carry with you for the rest of your career? Skimping yourself on a chair just doesn't make sense.

Although I've been quite happy with my Herman Miller Aeron chair over the last 10 years, I've always been a little disenchanted with the way it became associated with dot-com excess:

In the '90s, the Aeron became an emblem of the dot-com boom; it symbolized mobility, speed, efficiency, and 24/seven work weeks. The Aeron was a must-have for hot startups precisely because it looked the least like office furniture: It was more like a piece of machinery or unadorned engineering. The black Pellide webbing was durable, and hid whatever Jolt or Red Bull stains you might get on it. Held taut by an aluminum frame, the mesh allowed air to circulate and kept your body cool. What's more, the chair came in three sizes, like a personalized tool. Assorted knobs and levers allowed you to adjust the seat height, tilt tension, tilt range, forward tilt, arm height, arm width, arm angle, lumbar depth, and lumbar height. The Aeron was high-tech but sexy -- which was how the dot-commers saw themselves.

But baby-faced CEOs weren't drawn to the Aeron only for the way it looked. The Aeron was a visual expression of the anti-corporate zeitgeist, a non-hierarchical philosophy about the workplace. An office full of Aerons implicitly rejected the Fortune 500, coat-and-tie, brick-and-mortar model in which the boss sinks back in an overpriced, oversized, leather dinosaur while his secretary perches on an Office Max toadstool taking notes.

I recently had the opportunity to sit in a newer Herman Miller Mirra chair on a trip, and I was surprised how much more comfortable it felt than my classic Aeron.

The Mirra chair was an excellent recliner, too. I've been disappointed by how poorly the Aeron reclines. I actually broke my Aeron's recline pin once and had to replace it myself. So I've retrained myself not to recline, which is awkward, as I'm a natural recliner.

All this made me wonder if I should retire my Aeron and upgrade to something better. I liked the Mirra, but the comments to my original chair post have a lot of other good seating suggestions, too. Here are pictures and links to the chairs that were most frequently mentioned as contenders, in addition to the Mirra and Aeron pictured above:

Steelcase Think Chair

Steelcase Leap Chair

Ergohuman Mesh Chair

HumanScale Freedom Chair

HumanScale Liberty Chair

There were also some lesser known recommendations, such as the Haworth Zody chair, Nightingale CXO chair, BodyBilt ergo chairs, Hag kneeling chair, NeutralPosture ergo, the Chadwick Chair from the original designer of the Aeron, and something called the swopper.

Chair fit is, of course, a subjective thing. If you're investing $500+ in a chair, you'd understandably want to be sure it's "the one". The thing to do is find a local store that sells all these chairs and try them all out. Well, good luck with that. Don't even bother with your local big-box office supply chain. Your best bet seems to be back stores, as they tend to stock many of the more exotic chairs. Apparently they have a clientele of people who are willing to spend for comfort.

Reviews of individual chairs are relatively easy to find, but aren't particularly helpful in isolation. What we need is a multi-chair review roundup. The only notable roundup I know of is Slate's late 2005 Sit Happens: The Search for the Best Desk Chair. It's not as comprehensive as I would like, but it does have most of the main contenders. Notably, Slate's winner was the HumanScale Liberty.

Some other helpful resources I've found, both in the comments to this post, and elsewhere:

a multiple chair roundup at CrunchGear
a fantastic research page on chairs someone compiled
a multiple-chair roundup at UNC
another chair roundup at Consumer Search, as well as a meta-collection of roundups.
video demos of Leap, and the HumanScale Freedom / Liberty

If this is all a bit too much furniture porn for your tastes, I understand. As for me, I'm headed off to my local friendly neighborhood back store to figure out which of these chairs will best replace my aging Aeron. By my calculations, the Aeron cost me about $7 per month over its ten year lifetime; I figure my continued health and comfort while programming are worth at least that much.

Update: Since people have been asking, I ultimately decided the best fit and feel for me, personally, was the Herman Miller Mirra chair. It's a huge upgrade from my ten year old Aeron. It feels like three or four revisions better. For example, the front lip of the seat is adjustable, which addresses one of the major concerns I had with my Aeron -- as well as the vastly improved reclining I mentioned above. The only unexpected downside is that the plastic back is a little rough on the skin if you sit, er... shirtless. Although I am very pleased with my new shadow Mirra with citron back (pic), I urge you to do the research and try the chairs yourself before deciding.

[advertisement] Read the largest case study ever published about lightweight peer code review in Best Kept Secrets of Peer Code Review. Free book, free shipping.

The One Thing Every Software Engineer Should Know

Jeff Atwood — Thu, 23 Oct 2008 00:59:59 PDT

I'm a huge Steve Yegge fan, so It was a great honor to have Steve Yegge on a recent Stack Overflow podcast. One thing I couldn't have predicted, however, was one particular theme of Steve's experience at Google and Amazon that kept coming up time and time again:

If there was one thing I could teach every engineer, it would be how to market.

Not how to type, not how to write, not how to design a programming language, but marketing.

This is painful for developers to hear, because we love code. But all that brilliant code is totally irrelevant until:

people understand what you're doing
people become interested in what you're doing
people get excited about what you're doing

That, in a nutshell, is marketing. Just because you're a marketer doesn't necessarily mean you're a marketing weasel. Sure, the two things are highly correlated -- but at its core, marketing is little more than an intermediate level course on fundamental human communication. Not something us programmers have historically been so great at.

That's why even the hardest of hard-core programmers should be paying attention to people like Seth Godin. Steve was referring to marketing in the broader, more timeless sense of getting other people interested in your ideas.

After hearing Steve mention this several times on our podcast -- and having seen his related talk How to Ignore Marketing and Become Irrelevant in Two Easy Steps I suddenly realized why I was so fascinated with two particular books I recently discovered. Books I kept referring to, over and over, during the development of Stack Overflow.

Whatever You Think, Think the Opposite	It's Not How Good You Are, It's How Good You Want to Be

I couldn't put down these two small-format books from the late Paul Arden. Guess what Mr. Arden did for a living? That's right, he was an executive creative director for Saatchi & Saatchi -- an advertising firm.

I had been reading dirty books. Marketing books. By choice, even. I'm a bit embarrassed to admit this, because these are exactly the kinds of pithy little business books I usually make fun of other people for reading. But in reading these books, I realized that so much of what we do on Stack Overflow has nothing to do with how awesome our code is -- and everything to do with marketing.

We're all software developers here, so let me put this in terms programmers understand: Dungeons & Dragons character statistics. You know, the classics.

If you're a programmer, and you want to get better at your job every year, you might think that the most important character stat to build is coding. Let's call this INT. So at the end of many years of toil, you'll end up something like this:

str	6
dex	9
con	12
int	51
wis	13
chr	4

OK, you're a genius programmer who can code circles around everyone else. But you may never ship any of your code for reasons that you don't control. That's an illusion. You can control when, how, and where your code ships. You probably spent too much time building your code and not enough time as an advocate of your code. Did you explain to people what your code does, why it's cool and important? Did you offer reasons why your code is going to make their lives better, at least in some small way? Did you make it easy for people to find and use your code?

I believe most programmers will be better served in their professional career if they shoot for character development more along these lines:

str	16
dex	14
con	15
int	18
wis	16
chr	17

Sometimes, you become a better programmer by choosing not to program. I agree with Steve: if I could teach my fellow software engineers one thing, it would be how to market themselves, their code, and their project.

[advertisement] Peer code review without meetings, paperwork, or stopwatches? No wonder Code Collaborator won the Jolt Award.

Hardware is Cheap, Programmers are Expensive

Jeff Atwood — Thu, 18 Dec 2008 23:59:59 PST

Given the rapid advance of Moore's Law, when does it make sense to throw hardware at a programming problem? As a general rule, I'd say almost always.

Consider the average programmer salary here in the US:

You probably have several of these programmer guys or gals on staff. I can't speak to how much your servers may cost, or how many of them you may need. Or, maybe you don't need any -- perhaps all your code executes on your users' hardware, which is an entirely different scenario. Obviously, situations vary. But even the most rudimentary math will tell you that it'd take a massive hardware outlay to equal the yearly costs of even a modest five person programming team.

For example, I just bought two very powerful servers for Stack Overflow. Even after accounting for a third backup server and spare hard drives for the RAID arrays, my total outlay is around $5,000. These servers, compared to the ones we're on now, offer:

roughly 50% more CPU speed
2 to 6 times the memory capacity
almost twice the disk space (and it's a faster RAID 10 array)

Under this new hardware regime, we can expect average page response times to improve by about half. All that for less than one month of an average programmer's salary.

I'd say that's a great deal. A no-brainer, even.

Incidentally, this is also why failing to outfit your (relatively) highly paid programmers with decent equipment as per the Programmer's Bill of Rights is such a colossal mistake. If a one-time investment of $4,000 on each programmer makes them merely 5% more productive, you'll break even after the first year. Every year after that you've made a profit. Also, having programmers who believe that their employers actually give a damn about them is probably a good business strategy for companies that actually want to be around five or ten years from now.

Clearly, hardware is cheap, and programmers are expensive. Whenever you're provided an opportunity to leverage that imbalance, it would be incredibly foolish not to.

Despite the enduring wonder of the yearly parade of newer, better hardware, we'd also do well to remember my all time favorite graph from Programming Pearls:

Everything is fast for small n. When n gets large, that's when things start to go sideways. The above graph of an ancient Trash-80 clobbering a semi-modern DEC Alpha is a sobering reminder that the fastest hardware in the world can't save you from bad code. More specifically, poorly chosen data structures or algorithms.

It won't hurt to run badly written code on the fastest possible boxes you can throw at it, of course. But if you want tangible performance improvements, you'll often have to buckle down and optimize the code, too. Patrick Smacchia's lessons learned from a real-world focus on performance is a great case study in optimization.

Patrick was able to improve nDepend analysis performance fourfold, and cut memory consumption in half. As predicted, most of this improvement was algorithmic in nature, but at least half of the overall improvement came from a variety of different optimization techniques. Patrick likens this to his early days writing demo scene code on the Commodore Amiga:

In the early 90s, I participated in the Amiga demo scene. It's a great illustration of the idea that there is always room for better performance. Every demo ran on the same hardware. It was the perfect incentive for demo developers to produce more and more optimized code. For several years, every month some record was beaten: the number of 3D polygons, the number of sprites, or the number of dots displayed simultaneously at the rate of 50 frames per second. Over a period of a few years, the performance factor obtained was around 50x! Imagine what it means to perform a computation in one second that originally took an entire minute. This massive gain was the result of both better algorithms (with many pre-computations and delegations to sub-chips) and micro-optimizations at assembly language level (better use of the chip registers, better use of the set of instructions).

Patrick achieved outstanding results, but let's be clear: optimizing your code is hard. And sometimes, dangerous. It is not something you undertake lightly, and you'd certainly want your most skilled programmers working on it. To put it in perspective, let's dredge up a few classic quotes.

Rules of Optimization:
Rule 1: Don't do it.
Rule 2 (for experts only): Don't do it yet.
-- M.A. Jackson
"More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason - including blind stupidity."
-- W.A. Wulf

Programmers have a tendency to get lost in the details of optimizing for the sake of optimization, as I've noted before in Why Aren't My Optimizations Optimizing? and Micro-Optimization and Meatballs. If you're not extremely careful, you could end up spending a lot of very expensive development time with very little to show for it. Or, worse, you'll find yourself facing a slew of new, even more subtle bugs in your codebase.

That's why I recommend the following approach:

Throw cheap, faster hardware at the performance problem.
If the application now meets your performance goals, stop.
Benchmark your code to identify specifically where the performance problems are.
Analyze and optimize the areas that you identified in the previous step.
If the application now meets your performance goals, stop.
Go to step 1.

Always try to spend your way out of a performance problem first by throwing faster hardware at it. It'll often be a quicker and cheaper way to resolve immediate performance issues than attempting to code your way out of it. Longer term, of course, you'll do both. You'll eventually be forced to revisit those deeper algorithmic concerns and design issues with your code that prevent the application from running faster. And the advantage of doing this on new hardware is that you'll look like an even bigger hero when you deliver the double whammy of optimized code running on speedier hardware.

But until the day that Moore's Law completely gives out on us, one thing's for sure: hardware is cheap -- and programmers are expensive.

[advertisement] Did your buddy just get his ear chewed off for another server crash? Help him out by recommending PA Server Monitor. He just might buy you lunch. Download the Free Trial!

Programming: Love It or Leave It

Jeff Atwood — Mon, 29 Dec 2008 01:36:48 PST

In a recent Joel on Software forum post Thinking of Leaving the Industry, one programmer wonders if software development is the right career choice in the face of broad economic uncertainty:

After reading the disgruntled posts here from long time programmers and hearing so much about ageism and outsourcing, I'm thinking of leaving the industry. What is a good industry to get into where your programming skills would put you at an advantage?

Joel Spolsky responded:

Although the tech industry is not immune, programming jobs are not really being impacted. Yes, there are fewer openings, but there are still openings (see my job board for evidence). I still haven't met a great programmer who doesn't have a job. I still can't fill all the openings at my company.
Our pay is great. There's no other career except Wall Street that regularly pays kids $75,000 right out of school, and where so many people make six figures salaries for long careers with just a bachelors degree. There's no other career where you come to work every day and get to invent, design, and engineer the way the future will work.
Despite the occasional idiot bosses and workplaces that forbid you from putting up Dilbert cartoons on your cubicle walls, there's no other industry where workers are treated so well. Jesus you're spoiled, people. Do you know how many people in America go to jobs where you need permission to go to the bathroom?
Stop the whining, already. Programming is a fantastic career. Most programmers would love to do it even if they didn't get paid. How many people get to do what they love and get paid for it? 2%? 5%?

I tend to agree with Joel's brand of tough love. What he seems to be saying -- after taking my usual poetic license -- is this:

Programming: love it or leave it.

Unless you're fortunate enough to work for a top tier software development company, like Google, Microsoft, or Apple, you've probably experienced first hand the huge skill disparities in your fellow programmers. I'm betting you've also wondered more than once why some of your coworkers can't, well, program. Even if that's what their job description says.

Over the last twenty years, I've worked with far too many programmers who honestly had no business being paid to be a programmer. Now, I'm not talking about your average programmer here. We're all human, and we all make mistakes. I'm talking about the Daily WTF crew. People that actively give programming a bad name, and you, as their coworker, a constant headache.

Like Joel, I'm not ready to call the current conditions a new dot com bubble yet, because business is still quite good. But one of the (very) few bright spots of the previous bubble was that it weeded out all the people who didn't truly love software development. Once the incentive to become an overnight dot-com genius programmer millionaire was gone, computer science enrollment suddenly dropped precipitously at colleges across the country. The only people left applying for programming jobs were the true freaks and geeks who, y'know, loved this stuff. The kind of people I had originally enjoyed working with so much. At least until a bunch of careerist gold diggers suddenly showed up and started polluting our workplace.

As much as the dot com bubble sucked, I was intensely glad to see these people go. Now I'm wondering if the current economic conditions are an opportunity to clean house again.

I mean this in the nicest possible way, but not everyone should be a programmer. How often have you wished that a certain coworker of yours would suddenly have an epiphany one day and decide that this whole software engineering thing just isn't working out for them? How do you tell someone that the quality of their work is terrible and they'll never be good at their job -- so much so that they should literally quit and pursue a new career? I've wanted to many times, but I never had the guts.

Joel implied that good programmers love programming so much they'd do it for no pay at all. I won't go quite that far, but I will note that the best programmers I've known have all had a lifelong passion for what they do. There's no way a minor economic blip would ever convince them they should do anything else. No way. No how.

So if a programmer ever hints, even in passing, that they might possibly want to exit the field -- they probably should. I'm not saying you should be a jerk about it, obviously. But if someone has any doubt at all about programming as a career choice, they should be encouraged to explore alternatives -- and make room for another programmer who unashamedly loves to code.

Then again, maybe I'm not the best person to ask. I spent Christmas Eve setting up servers. I'm on holiday right now, sitting in a hotel room in Santa Barbara, and you know what I spent the last two nights doing until the wee hours of the morning? Writing code to improve Stack Overflow. Oh yeah, and this blog post.

So I might be a little biased.

[advertisement] Tired of restoring deleted files? Get PA File Sight and track down the culprit. PA File Sight – file auditing made easy. Download the Free Trial!

Top 25 Most Dangerous Programming Mistakes

Jeff Atwood — Mon, 12 Jan 2009 23:59:59 PST

I don't usually do news and current events here, but I'm making an exception for the CWE/SANS Top 25 Most Dangerous Programming Errors list. This one is important, and deserves a wide audience, so I'm repeating it here -- along with a brief hand-edited summary of each error.

If you work on software in any capacity, at least skim this list. I encourage you to click through for greater detail on anything you're not familiar with, or that piques your interest.

Improper Input Validation
Ensure that your input is valid. If you're expecting a number, it shouldn't contain letters. Nor should the price of a new car be allowed to be a dollar. Incorrect input validation can lead to vulnerabilities when attackers can modify their inputs in unexpected ways. Many of today's most common vulnerabilities can be eliminated, or at least reduced, with strict input validation.
Improper Encoding or Escaping of Output
Insufficient output encoding is at the root of most injection-based attacks. An attacker can modify the commands that you intend to send to other components, possibly leading to a complete compromise of your application - not to mention exposing the other components to exploits that the attacker would not be able to launch directly. When your program generates outputs to other components in the form of structured messages such as queries or requests, be sure to separate control information and metadata from the actual data.
Failure to Preserve SQL Query Structure (aka 'SQL Injection')
If attackers can influence the SQL that you send to your database, they can modify the queries to steal, corrupt, or otherwise change your underlying data. If you use SQL queries in security controls such as authentication, attackers could alter the logic of those queries to bypass security.
Failure to Preserve Web Page Structure (aka 'Cross-site Scripting')
Cross-site scripting (XSS) is a result of combining the stateless nature of HTTP, the mixture of data and script in HTML, lots of data passing between web sites, diverse encoding schemes, and feature-rich web browsers. If you're not careful, attackers can inject Javascript or other browser-executable content into a web page that your application generates. Your web page is then accessed by other users, whose browsers execute that malicious script as if it came from you -- because, after all, it did come from you! Suddenly, your web site is serving code that you didn't write. The attacker can use a variety of techniques to get the input directly into your server, or use an unwitting victim as the middle man.
Failure to Preserve OS Command Structure (aka 'OS Command Injection')
Your software acts as a bridge between an outsider on the network and the internals of your operating system. When you invoke another program on the operating system, and you allow untrusted inputs to be fed into the command string, you are inviting attackers into your operating system.
Cleartext Transmission of Sensitive Information
Information sent across a network crosses many different nodes in transit to its final destination. If your software sends sensitive, private data or authentication credentials, beware: attackers could sniff them right off the wire. All they need to do is control one node along the path to the final destination, any node within the same networks of those transit nodes, or plug into an available interface. Obfuscating traffic using schemes like Base64 and URL encoding offers no protection.
Cross-Site Request Forgery (CSRF)
Cross-site request forgery is like accepting a package from a stranger -- except the attacker tricks a user into activating a HTTP request "package" that goes to your site. The user might not even be aware that the request is being sent, but once the request gets to your server, it looks as if it came from the user -- not the attacker. The attacker has masqueraded as a legitimate user and gained all the potential access that the user has. This is especially handy when the user has administrator privileges, resulting in a complete compromise of your application's functionality.
Race Condition
A race condition involves multiple processes in which the attacker has full control over one process; the attacker exploits the process to create chaos, collisions, or errors. Data corruption and denial of service are the norm. The impact can be local or global, depending on what the race condition affects - such as state variables or security logic - and whether it occurs within multiple threads, processes, or systems.
Error Message Information Leak
Chatty error messages can disclose secrets to any attacker who misuses your software. The secrets could cover a wide range of valuable data, including personally identifiable information (PII), authentication credentials, and server configuration. They might seem like harmless secrets useful to your users and admins, such as the full installation path of your software -- but even these little secrets can greatly simplify a more concerted attack.
Failure to Constrain Operations within the Bounds of a Memory Buffer
The scourge of C applications for decades, buffer overflows have been remarkably resistant to elimination. Attack and detection techniques continue to improve, and today's buffer overflow variants aren't always obvious at first or even second glance. You may think that you're completely immune to buffer overflows because you write your code in higher-level languages instead of C. But what is your favorite "safe" language's interpreter written in? What about the native code you call? What languages are the operating system API's written in? How about the software that runs Internet infrastructure?
External Control of Critical State Data
If you store user state data in a place where an attacker can modify it, this reduces the overhead for a successful compromise. Data could be stored in configuration files, profiles, cookies, hidden form fields, environment variables, registry keys, or other locations, all of which can be modified by an attacker. In stateless protocols such as HTTP, some form of user state information must be captured in each request, so it is exposed to an attacker out of necessity. If you perform any security-critical operations based on this data (such as stating that the user is an administrator), then you can bet that somebody will modify the data in order to trick your application.
External Control of File Name or Path
When you use an outsider's input while constructing a filename, the resulting path could point outside of the intended directory. An attacker could combine multiple ".." or similar sequences to cause the operating system to navigate out of the restricted directory. Other file-related attacks are simplified by external control of a filename, such as symbolic link following, which causes your application to read or modify files that the attacker can't access directly. The same applies if your program is running with raised privileges and it accepts filenames as input. Similar rules apply to URLs and allowing an outsider to specify arbitrary URLs.
Untrusted Search Path
Your software depends on you, or its environment, to provide a search path (or working path) to find critical resources like code libraries or configuration files. If the search path is under attacker control, then the attacker can modify it to point to resources of the attacker's choosing.
Failure to Control Generation of Code (aka 'Code Injection')
While it's tough to deny the sexiness of dynamically-generated code, attackers find it equally appealing. It becomes a serious vulnerability when your code is directly callable by unauthorized parties, if external inputs can affect which code gets executed, or if those inputs are fed directly into the code itself.
Download of Code Without Integrity Check
If you download code and execute it, you're trusting that the source of that code isn't malicious. But attackers can modify that code before it reaches you. They can hack the download site, impersonate it with DNS spoofing or cache poisoning, convince the system to redirect to a different site, or even modify the code in transit as it crosses the network. This scenario even applies to cases in which your own product downloads and installs updates.
Improper Resource Shutdown or Release
When your system resources have reached their end-of-life, you dispose of them: memory, files, cookies, data structures, sessions, communication pipes, and so on. Attackers can exploit improper shutdown to maintain control over those resources well after you thought you got rid of them. Attackers may sift through the disposted items, looking for sensitive data. They could also potentially reuse those resources.
Improper Initialization
If you don't properly initialize your data and variables, an attacker might be able to do the initialization for you, or extract sensitive information that remains from previous sessions. If those variables are used in security-critical operations, such as making an authentication decision, they could be modified to bypass your security. This is most prevalent in obscure errors or conditions that cause your code to inadvertently skip initialization.
Incorrect Calculation
When attackers have control over inputs to numeric calculations, math errors can have security consequences. It might cause you to allocate far more resources than you intended - or far fewer. It could violate business logic (a calculation that produces a negative price), or cause denial of service (a divide-by-zero that triggers a program crash).
Improper Access Control (Authorization)
If you don't ensure that your software's users are only doing what they're allowed to, then attackers will try to exploit your improper authorization and exercise that unauthorized functionality.
Use of a Broken or Risky Cryptographic Algorithm
Grow-your-own cryptography is a welcome sight to attackers. Cryptography is hard. If brilliant mathematicians and computer scientists worldwide can't get it right -- and they're regularly obsoleting their own techniques -- then neither can you.
Hard-Coded Password
Hard-coding a secret account and password into your software is extremely convenient -- for skilled reverse engineers. If the password is the same across all your software, then every customer becomes vulnerable when that password inevitably becomes known. And because it's hard-coded, it's a huge pain to fix.
Insecure Permission Assignment for Critical Resource
Beware critical programs, data stores, or configuration files with default world-readable permissions. While this issue might not be considered during implementation or design, it should be. Don't require your customers to secure your software for you! Try to be secure by default, out of the box.
Use of Insufficiently Random Values
You may depend on randomness without even knowing it, such as when generating session IDs or temporary filenames. Pseudo-Random Number Generators (PRNG) are commonly used, but a variety of things can go wrong. Once an attacker can determine which algorithm is being used, he can guess the next random number often enough to launch a successful attack after a relatively small number of tries.
Execution with Unnecessary Privileges
Your software may need special privileges to perform certain operations; wielding those privileges longer than necessary is risky. When running with extra privileges, your application has access to resources that the application's user can't directly reach. Whenever you launch a separate program with elevated privileges, attackers can potentially exploit those privileges.
Client-Side Enforcement of Server-Side Security
Don't trust the client to perform security checks on behalf of your server. Attackers can reverse engineer your client and write their own custom clients. The consequences will vary depending on what your security checks are protecting, but some of the more common targets are authentication, authorization, and input validation.

Of course there's nothing truly new here; I essentially went over the same basic list in Sins of Software Security almost two years ago. The only difference is the relative priorities, as web applications start to dominate mainstream computing.

This list of software security mistakes serves the same purpose as McConnell's list of classic development mistakes: to raise awareness. A surprisingly large part of success is recognizing the most common mistakes and failure modes. So you can -- at least in theory -- realize when your project is slipping into one of them. Ignorance is the biggest software project killer of them all.

Heck, even if you are aware of these security mistakes, you might end up committing them anyway. I know I have.

Have you?

[advertisement] Did your buddy just get his ear chewed off for another server crash? Help him out by recommending PA Server Monitor. He just might buy you lunch. Download the Free Trial!