The "Bucket Bumping" problem of airline tickets, and how to minimise your fare

The problem

You're booking your next holiday and while checking prices you key in the search for one passenger. When it comes time to make the actual booking, you select the required four passengers for your family, but suddenly the price per ticket rises from $250 to $400! 

Why it happens

Airline booking systems (aka Global Distribution Systems / GDS) cannot split a single booking across "buckets" (fare classes). If there are two seats left at $250 and you need four, the system doesn't give you two at $250 and two at $400 (which would be common sense). It bumps the entire group into the higher bucket, which is $400 per ticket.

The UI rarely explains this. It just silently adjusts the price for everyone, hoping you'll just put it down to tickets selling out quickly right now, or some other cause like dynamic pricing.

The root cause

Its caused by a 50-year-old legacy backend design. Airlines use buckets, denoted by single letters (Y, B, M, K, L, etc.). The GDS treat a booking as an atomic unit, so if you search for a party of four, the system only tries to find four seats within the same fare bucket.

Example - when a booking engine sends a "Sell Request" to the backend, it sends a single message:

SELL 4 SEATS IN CLASS Q

The legacy backend that receives the request is pretty basic - it doesn't have the ability to apply the logic, "I only have 2 left in Q, so I'll give you those and put the remaining 2 in M." It instead just looks at the remaining seats in Class Q.

If Available < Requested, it returns:

ERROR CLASS UNAVAILABLE

The booking middleware is programmed to catch that error and retry the request for the next bucket letter, until it finds a bucket which has the required number of total seats available, which means the request succeeds.

How to minimise your group fare

Given this limitation, how can you ensure you always pay the minimum possible? Its a pretty simple method - the one-by-one search technique. Search for one passenger first. Keep incrementing the number of passengers you search for, until the price per ticket bumps up. Then you know how many seats remain in the cheapest bucket. So exhaust that cheapest bucket before going ahead with the the rest of your booking. 

Why don't Airlines fix it?

So why haven't they fixed this core issue - that's in fact a "group booking tax"? The answer is likely technical debt on a global scale combined with the lack of a financial incentive. To change it, you’d have to synchronize updates across tens of thousands of travel agencies, hundreds of airlines, and third-party aggregators. 

Rather than fixing the root issue, the industry just builds layers of shiny new wrapper APIs on top of the same legacy core. Another name for this is pig's lipstick code.

Follow @dodgy_coder on X

Quick Fix Archaeology - 3 famous hacks that changed the world

We’ve all been there... it’s 2pm on a Friday and you’ve just found a bug that defies logic. You don't have time for a robust architectural solution. You have time for a few lines of code that will do the job.

You then tell yourself the biggest lie in software development: I’ll refactor this later. In reality, that temporary hack often ends up becoming the foundation of the entire system. 

If you feel guilty about the random spaghetti code currently holding your production environment together, take heart. Some of the most iconic features in tech history weren't the result of visionary genius or months of planning. They were accidents, hardware limitations, and temporary placeholders that refused to die.

From a core function of the Windows O/S, to the games that defined a generation, the software industry is built on a pile of good enough Friday afternoon hacks that accidentally changed the world.

Here's three famous examples of random hacks that became permanent legends.

1. The Windows Format Dialog's 30 Year Legacy

If you’ve used Windows at any point in the last thirty years, you’ve seen it: the utilitarian, grey format drive dialog box. It’s got a few dropdowns, a quick format checkbox, and a rigid refusal to format any drive larger than 32GB as FAT32.

You might assume a committee of Microsoft architects spent months weighing the trade-offs of cluster sizes and file system overhead to arrive at that 32GB limit.

How it went down: It was one guy, a rainy Thursday morning, and a massive case of this'll do for now.

In 1994, developer Dave Plummer was busy porting the user interface from Windows NT to Windows 95. He reached the Format tool and realized the existing UI wasn't going to cut it. So, he pulled out a piece of paper, noted down the features he thought a user might need (filesystem, cluster size, label), and whipped up a basic vertical stack of options.

He didn't like the look of it. It was meant to be a rough draft, a placeholder that someone else would prettify. To top it off, he had to decide on a maximum volume limit for the FAT32 format. He arbitrarily picked 32GB as the cap, thinking that would be plenty for the hardware of the mid-90s and that someone would eventually write a better tool to replace his placeholder.

The result: Microsoft never replaced it. Dave's Format dialog survived through Windows 98, XP, Vista, 7, 10, and its still there in Windows 11.

Because of that one quick fix, a generation of IT professionals grew up thinking 32GB was a fundamental limitation of the FAT32 architecture. In reality, it was just the limit of Dave's patience that morning. It is perhaps the longest term temporary UI in the history of computing.

2. Space Invaders: The Difficulty Curve Born from Lag

In modern game design, we talk about pacing and difficulty curves like they are sacred sciences. Designers spend hundreds of hours tweaking variables to ensure a game gets progressively harder as the player gets better.

But in 1978, Tomohiro Nishikado, the creator of the classic video game Space Invaders, didn’t have a difficulty setting variable. He had a much bigger problem: the CPU of the 8-bit Intel 8080 was struggling to keep up.

How it went down: The custom game hardware Nishikado built was, by today’s standards, incredibly underpowered. When the game started, the screen displayed 55 alien invaders and the processor was completely maxxed out. It could barely handle rendering all the sprites let alone moving them across the screen. As a result, the aliens moved in a sluggish, rhythmic crawl, left to right, down, right to left, etc.

But as the player started blasting the invaders, something unintended happened. With every alien removed from the screen, the CPU had one less thing to render. The lighter the load, the faster the processor could loop through the code.

The fewer enemies there were, the faster the remaining ones moved.

The result: Instead of trying to fix the timing (which would have been an engineering nightmare on that hardware), Nishikado realized the bug made the game incredibly tense. The frantic thump-thump-thump of the final few invaders zipping across the screen felt like a deliberate design choice to pressure the player.

He left it in.

In doing so, he accidentally invented the Difficulty Curve. It wasn't a line of code that made the game harder; it was the hardware finally being able to breathe. Next time your app slows down under heavy load, don't call it a performance bottleneck... call it Emergent Gameplay.

3. Street Fighter II: The Bug That Built eSports

If you’ve ever played a fighting game and pulled off a three-hit combo, you owe a debt of gratitude to a piece of code that was technically failing at its job.

In the early 90s, the concept of canceling one animation into another didn't exist. Fighting games were polite; you punched, the animation finished, and then you were allowed to punch again. But during the development of Capcom's Street Fighter II, lead designer Noritaka Funamizu noticed something strange while testing.

How it went down: Funamizu was checking the timing of the special moves (e.g. the Hadouken). To make these complex inputs easier for players to pull off, the developers had added a key input buffer... a small window of time where the game would accept a new input - even if the previous animation hadn't quite finished yet.

He discovered that if he timed hitting buttons perfectly, he could land a normal punch and then cancel the rest of that animation by triggering a special move. This allowed him to hit the opponent twice before they even had a chance to recover.

The result: Funamizu thought the timing was so incredibly difficult to get right that no one would ever be able to reproduce it reliably. He figured it was a hidden quirk that wasn't worth the effort to fix or re-code.

He was wrong.

Players discovered it almost immediately. What Funamizu dismissed as a timing bug became the Combo System. It transformed fighting games from slow, back-and-forth matches into high-speed, technical displays of skill. Today, canceling is a core mechanic in almost every fighting game on the market, all because a Capcom designer found a quirky bug and let it stay in.

In Defense of the Hack

So, what’s the lesson here - should we all start writing half baked quick fixes and hope for a miracle? Not exactly.

But there is a profound truth in these stories: Perfect is the enemy of shipped. The Windows format tool wasn't a masterpiece of UI design, but it solved a problem on a rainy Thursday. Space Invaders lagged because the code didn't take into account the hardware, but it created the sort of tense atmosphere that a clean engine never could. These devs weren't aiming for historical legacy; they were just trying to get the job done with the tools and time at hand.

The next time you’re coding a workaround, don't just see it as a hack. You might be looking at a future industry standard. Or at the least, the duct tape that keeps your company going for another 12 months. So, go forth and ship it - you can always refactor it... later.

Further Reading & Sources

- Dave Plummer’s YouTube Channel: The original Windows developer himself tells the story of the Format Dialog and the 32GB limit.

- A detailed look at how Tomohiro Nishikado invented the difficulty curve by accident, and the hardware limitations he faced.

- The Making of Street Fighter II: How the accidental combo system came about, and why Noritaka Funamizu decided to keep it.

Follow @dodgy_coder on X

The Art of Developing Software

The below is taken from an interview conducted at the Computer History Museum in 2004 by Grady Booch. He interviewed early Apple developers Bill Atkinson and Andy Hertzfeld about the development of the original Apple Mac, and in particular MacPaint software.

On the art of developing software

Grady Booch: So what makes software beautiful for you? Do you care about the beauty of software?

Bill Atkinson: Oh yes, it’s an art form, like any other art form, and it’s not just practical, as in, does it do the job? Is it clean inside, does it look--? I would spend time rewriting whole sections of code to make them more cleanly organized, more clear. 

I’m a firm believer that the best way to prevent bugs is to make it so that you can read through the code and understand exactly what it’s doing, that there’s nothing tricky in it, that it’s all very straightforward. And maybe that was a little bit counter to what I ran into when I first came to Apple. 

There were a lot of people who prided themselves in how this little piece does something that I can’t for the life of me figure out what it is, but it’s magic that it does it. I would do things like deliberately assign something into a variable, and instead of putting ten operations concatenated onto one line, I’d use intermediate variables so I could understand the purpose of each of these. And I liked it. 

I found that if I spent time going over the code, cleaning it up, making it sometimes tighter – I did a lot of measurement and tried to make the performance good – but also making it so that it was straightforward so another person could follow in my footsteps, then I would feel proud of it.

Grady Booch: Don Knuth was telling me that he felt that MacPaint was perhaps one of the most beautiful programs he has ever seen, just in terms of its readability. 

On the MacPaint development process

Bill Atkinson: I had a different method of software developing than Randy Wiggington who was developing MacWrite. We had two different philosophies. Mine was you don’t get to add any new features until what you’ve got is working reliably, solidly; and his was, let’s add all the new features and then let’s debug them. I just think that that’s a bad way to do it because finding bugs is a very unlikely proposition. If you search really hard you might find half the bugs that are there, and the others are going to bite you and you just don’t know when. So I had a little more conservative approach to design.

Grady Booch: What you describe is very similar to what the Agile community speaks of these days; always have something executable through incremental development. And it’s very cool.

Andy Hertzfeld: Yes, yes, that’s really how the Mac was developed.

Grady Booch: You were the first Agiles. So by my count, or others, MacPaint was about 5,804 lines of Pascal and so on; 2,738 lines of assembly language.

Bill Atkinson: Plus all of the QuickDraw I’d built on top, because without QuickDraw you couldn’t do all that stuff.

Grady Booch: And pretty much everything had built upon QuickDraw.

Andy Hertzfeld: Yes.

Bill Atkinson: There were 70,000 lines of assembly language [in QuickDraw]. 

More reading
Computer History Museum: Oral History of Andy Hertzfeld and Bill Atkinson
Revolution in The Valley: The Insanely Great Story of How the Mac Was Made, by Andy Hertzfeld
Folklore: Anecdotes about the development of Apple's original Macintosh
BYTE Magazine (1984): An Interview: The Macintosh Design Team

Follow @dodgy_coder on X

Does Xamarin owe its existence to Unity & Apple?

Yes, Xamarin owes its existence to two other bits of technology that were huge around 2008 - the Unity Game Engine and the iPhone. The reason is that a confluence of events around 2008 provided the push to get the Mono project into mobile app development. This resulted in MonoTouch (for iOS) and Mono for Android, which eventually became Xamarin as we know it today.

The Mono project was founded in 2001 as a free open source implementation of Microsoft's .NET framework on Linux. But Mono had struggled since its inception to find its reason for being. According to Mono's founder, Miguel De Icaza, the hardcore free open source community never fully got behind Mono. The FOSS community feared that Microsoft would eventually cause problems for Mono, due to Microsoft being the creator of .NET. 

Outside of the Linux world however were other more pragmatic people from the MacOSX world who had no problem with Mono. One of these people was Joachim Ante, from Unity. Around 2005 the Unity game engine was just starting out and had a performance problem - their original scripting language of Python was far too slow - they needed something that was an order of magnitude faster. So Unity decided to replace the Python scripting with Mono/C# and immediately got all the performance they needed. This was the early days when the Unity Game Engine ran on MacOSX only. Mono filled the need of being a free open source JIT compiler with the modern language of C#.

Fast forward to 2008 when the iPhone App Store launched; Unity quickly set their sights on being able to compile games for the iPhone. Unity wanted to use Mono, but the additional requirement was that it had to be statically compiled for iOS, because Apple had banned the use of JIT (Just In Time) compilers in iOS Apps.

Unity comes back to us and says “Hey, we have this product on iOS, we need .NET to be statically compiled. Can you do that?” We were like, “Oh, that’s kind of impossible. Well, let’s think about it.”

One of our guys, Zoltán Varga - they went and made a static compiler for .NET, and it was amazing. We gave it to Unity. At this point, Unity is probably four or five employees.
    
They were working at somebody’s garage. And they shipped their product for iOS, built games for iOS using this thing, this 3D tech. They were the kings of this space.
    
- Miguel De Icaza (Xamarin)

Within a year of the iPhone App Store launch, Unity went from 4-5 employees to 80 employees. The iPhone and the App Store had launched Unity's massive growth, and along with this the Mono project had finally found its reason for being - mobile apps. The Mono developers realised there was interest in using .NET for mobile apps - so using the same tech given to Unity, they built their own product - MonoTouch, which allowed developers build native iOS apps using C#. Soon afterward, Mono turned its attention to Android and created Mono for Android.

Mobile app development was new and there were many developers who wanted to get into mobile apps but didn't really want to have to learn Objective-C and Java. So Mono now had a C# based cross platform app development platform with truly native performance. This was the killer combination that ensured Mono would take off in popularity.

The developers behind Mono founded the Xamarin company in 2011, MonoTouch became Xamarin.iOS and Mono for Android became Xamarin.Android. Xamarin was acquired by Microsoft in February 2016 and became a subsidiary of Microsoft, fully focused on the development of Xamarin's open source projects.

Inspiration for this article:

The History of GNOME, Mono, and Xamarin
https://changelog.com/podcast/275

Follow @dodgy_coder on Twitter

Anders Hejlsberg: C# stands for C++++

Just came across this today. Previously had heard the association with the musical sharp symbol (#) to mean a pitch higher in tone, but this was the first time I'd heard that the # symbol can also be seen as a matrix of four small + symbols, hence C# stands for C++++, i.e. an increment to C++.

Source: http://www.computerworld.com.au/article/261958/a-z_programming_languages_c_/?pp=2

Follow @dodgy_coder

Subscribe to posts via RSS

Android development is the new .NET

Back in 2001 Microsoft Windows had 90% of the worldwide OS market for PCs. But desktop windows software development was dire.

Developers were using tools like ...

• Visual Basic 6 - very productive, with the downside of ugly, primitive syntax, lacking modern features such as interfaces and classes.
• Visual C++/MFC - serious windows developers were using this, but it was less productive and extremely verbose, with lots of boilerplate.
• Delphi -  the successor of Turbo Pascal and possibly the best of all frameworks on Windows at the time, but it never really took off.
• Borland C++/OWL - the Open Windows Library from Borland tracked pretty closely with Visual C++/MFC, verbose + boilerplate.
• Java - this had a reputation on Windows at the time for slow performance, bad visuals and bad tools.

At this point, Microsoft came out with Visual Studio.NET, the .NET framework and a new language named C#, with the help of former Delphi & Turbo Pascal language designer Anders Hejlsberg. Most Windows developers got on board - compared to what came before it was a breath of fresh air. Since that time, .NET has remained a large player, especially in the corporate and business market.

Fast forward to 2014, Android now has an 80% worldwide market share of approx. 1.75 billion smart phones.

Google has their own IDE, Android Studio and the open source Android SDK, which you can program using Java or any other JVM language. In the same way that .NET lets you use different .NET compatible languages such as C++/CLI and F#, Android supports other JVM languages like Scala, Clojure and Groovy, all of which let you cut down on the verbosity and boilerplate of Java.

Google is attempting to bring as many developers over to Android as possible. Their Head of Scalable Developer Relations, Reto Meier, aims to bring 50 million developers to Android.

Based on Android's market share and future employment prospects, Android is a decent choice for developers to try out. Compared to iOS, Android isn't as performant or profitable, but now it has a decent IDE, the weight of numbers, and the capability to use many Java FOSS libraries.

Follow @dodgy_coder

Subscribe to posts via RSS

Google's fiber leeching caper

Back in 2000, Google only had data centers on the US west coast and were planning an expansion over to the east coast, to reduce latency to end users. At the time, Google was not hugely profitable like today, and were very conscious of costs. One of the biggest costs of the move was duplicating the data contained in their search indexes over onto the east coast. Google had just passed indexing 1 billion web pages, and had around 9 terabytes of data contained in their indexes. They calculated that even at the highest speed of 1 Gigabit per second, it would take 20 hours to transfer all the data, with a total cost of $250,000.

Larry and Sergey had a plan however, and it centered on exploiting a loophole in the common billing practice known as burstable billing, which is employed by most large bandwidth suppliers. The common practice is to take a bandwidth usage reading every 5 minutes for the whole month. At the end of the month, the top 5% of usage information is discarded, to eliminate spikes (bursts). They reasoned that if they transferred data for less than 5% of the entire month (e.g. for 30 hours), and didn't use the connection at all outside that time, they should be able to get some free bandwidth.

So for 2 nights a month, between 6pm and 6am pacific time, Google pumped the data from their west coast data center to their new east coast location. Outside of these 2 nights, the router was unplugged. At the end of the month the bill came out to be nothing.

They continued like this every month until the contract with their bandwidth supplier ended, and they were forced to negotiate a new one, which meant actually paying for their bandwidth. By this time, Google had started buying up strategically located stretches of fiber, paving the way for its own fiber network to support its increasing bandwidth needs.

Source:

In The Plex: How Google Thinks, Works, and Shapes Our Lives [Amazon]
By Steven Levy
Published: April 12, 2011
See pages 187-188, Steven Levy's interview with Urs Hölzle and Jim Reese.

Follow @dodgy_coder

Subscribe to posts via RSS

The slow decline of PCs and the fast rise of Smartphones/Tablets was predicted in 1993

I've just read some predictions for the future of the PC, written in 1993, by Nathan P. Myhrvold, the former Chief Technology Officer at Microsoft.

His memo is amazingly accurate. Note that his term "IHC" (Information Highway Computer) could be roughly equated with today's smartphone or tablet device, connecting to the Internet via WiFi or a cellular network. In his second last paragraph, Myhrvold predicts the winners will be those who "own the software standards on IHCs" which could be roughly equated with today's app stores, such as those on iOS (Apple), Android (Google, Amazon) and Windows 8 (Microsoft).

The only thing you could say he possibly didn't foresee would be the importance of hardware design in the new smartphone and tablet industry. I'd suggest that Apple achieved such a head start on their competition through a combination of both cutting edge hardware design along with their curated app store model for distributing software. Interestingly, Microsoft has only last month entered the hardware game with their new Surface brand tablets for Windows 8 and Windows RT, and also announced a shift to focus on becoming a "Devices and Services" company.

Note: the term "Cairo" used below is the code name for a Microsoft Research project which lasted from 1991 to 1996. It resulted in some features that were eventually rolled into Windows 95, IIS and SQL Server.


The below is an extract from a memo written by Nathan P. Myhrvold, titled "Road Kill on the Information Highway". September 8, 1993. Full Source. 

Personal Computers
I've saved the best for last.  Our own industry is also doomed, and will be one of the more significant carcasses by the side of the information highway.  The basic tasks that PCs are used for today will continue for a long as it makes sense to predict, so it isn't a question of the category disappearing.  The question is one of who will continue to satisfy these needs and how? 

As a case in point, consider that the fundamental category needs for mainframes and minicomputers also still exists and will continue to do so for a very long time.  Despite this, the companies involved are dying and the entire genre is likely to disappear.  The reason is that a new breed of machine - the PC - came along which out flanked them.  In the early years PCs were not particularly good at what minis and mainframes did, but they were terrific at a whole new set of problems that the traditional computing infrastructure had basically ignored.  

Personal productivity applications drove PCs onto millions of desks and created a very vital industry which grew faster - both in business terms and price/performance - than the mainframe and minicomputer markets.   The power conferred by this growth made PCs the tail which wagged the dog; free to ignore the standards which existed for mainframes and minis and move off on their own.   Over time the exponential growth in computing has finally (after 17 years) given the PC industry the technical ability to beat minis and mainframes in their own domain.   Although the early software platforms for PCs had to be extended to fully realize this potential (DOS to Windows to NT to Cairo), it turned out to be far easier to do this than to make mainframe or minicomputer systems address the new needs and applications.   Even within the heart of minicomputer and mainframe's domain - giant transaction processing applications etc., the old standards will not be used.  

I believe that the same thing will happen again with PCs playing the role of mainframes and minis, and the computing platforms of the information highway taking over the role of the challenger.   

The technical needs of computers on the information highway, or IHCs are quite different than for PCs.  The killer applications for IHCs in the early years will include video on demand, games, video telephony and other distributed computing tasks on the highway.  It is hard to classify this as either higher tech or lower tech than the software for PCs, because the two are quite different.   Most IHCs will certainly need to be cheaper than PCs by an order of magnitude and this will inevitably cause them to be less capable in many ways, but some of their requirements are far more advanced. 

Another way to say this is that the rich environment of software for PCs is largely irrelevant for IHCs.   Windows, NT, System 7 and Cairo do not solve the really important technical problems required for IHC applications, and it is equally likely that the early generations of IHC software won't be great platforms for PC style apps.  This isn't surprising because they are driven by an orthogonal set of requirements. 

The IHC world will almost certainly grow faster than PCs, both in business terms and in price/performance.   The PC industry is already reaching saturation from a business perspective.  Technically speaking, the industry is mired in hardware standards (Intel and Motorola CISC processors)  with growth rates that are flattening out relative to the state of the art - just as the 360/3090 and VAX architectures did.   The Macintosh and Windows computing environments may be able to survive the painful transition to new RISC architectures, but they will lose time and momentum in doing so.    

PCs will remain paramount within their domain for many years (we'll still have a computer on every desk) but IHCs will start to penetrate a larger and larger customer base on the strength of its new and unique applications.   The power of having the worlds information - and people - on line at any time is too compelling to resist.   For a long time people will still have a traditional PC to handle traditional PC tasks - in precisely the same way that they have kept their mainframes and minis for the last 17 years.   One day however people will realize that their little IHCs are more powerful and cheaper than PCs - just as we have finally done with mainframes.   There will be a challenge for the IHC software folks to write the new systems and applications software necessary to obviate PCs, just as we had to work pretty hard to come up with NT, but this battle will clearly go to the companies who own the software standards on IHCs.  The PC world won't have any more say about how this is done than the companies who created MVS or VMS did about our world.  Of course, some of the VMS people were involved, but as discussed above it is very hard for organizations to make the transition. 

This may sound like a rather dire prediction, but I think that for the most part it is inevitable.  The challenge for Microsoft is to be sufficiently involved with the software for the IHC world that we can be a strong player in that market.  If we do this then we will be able to exploit a certain degree of synergy between IHCs and PCs - there are some natural areas where there is benefit in having the two in sync.  The point made above is that those benefits are not sufficiently strong that they alone will give us a position in the new world.   We'll live or die on the strength of the technology and role that we carve out for ourselves in the brave new world of the information highway. 

Many thanks to Reddit user erpettie who originally submitted a link to this memo on /r/technology,which is how I came across it.

Follow @dodgy_coder

Subscribe to posts via RSS 

Q&A With Nine Great Programmers

This Q&A article is originally from 2006, published on the blog of Polish developer Jaroslaw "sztywny" Rzeszótko (AKA "Stiff").  That original blog post is no longer online. Gratefully republished with his permission.

On a hot, boring afternoon I got an idea. With the help of publicly accessible e-mail addresses, I asked 10 questions to a bunch of programmers that I consider very interesting people and I respect them for various things they created. Coming out with the questions was a 5 minute job for me - these are things I would ask about if I could speak with them personally for, let’s say, 10 minutes, and I didn’t have time for thinking too much. The last two question don’t have anything to do with programming, this is simply something I like to know about everyone I talk to, lets say that’s my hobby. Not everyone wanted to answer them, and that’s fine. It was the first "interview" I ever made, so I also made some mistakes, which went out as people started answering. But despite this, I learnt a lot of interesting stuff, so it was definitely a valuable experience.

Not everyone responded to my e-mail, not everyone agreed to answer the questions, maybe I will also get some answers after I published this, I didn’t have the patience to wait longer, so new things may appear here over time (Update: Bjarne Stroustrup was added on 03.08.2006).
-- Jaroslaw

Starring

Linus Torvalds - The Linux kernel author.

Dave Thomas - Author of the "Pragmatic Programmer", "Programming Ruby" and other great books about programming. One can read his mainly programming-related thoughts here.

David Heinemeier Hansson - Author of the Rails Framework - the new hot web development framework. He has a blog here.

Steve Yegge - Probably one of the least known guys here, but he also sent most interesting answers. He has a popular blog about programming. He is also the author of a game called "Wyvern".

Peter Norvig - Research Director at Google, a well known Lisper, author of famous (in some circles at least) books about AI. See his homepage here.

Guido Van Rossum - The Python language creator.

Bjarne Stroustrup - C++ language creator, has a homepage here.

James Gosling - The Java language creator.

Tim Bray - One of the XML and Atom specifications author and a blogger too.


Q 1: How did you learn programming? Were any schools of any use? Or maybe you didn’t even bother with ending any schools :) ?

Steve Yegge
I taught myself to program on an HP calculator using their RPN stack language when I was 17 years old. I’d tried to learn programming a few times before that but never really "got" it. The HP 28c and 48g scientific calculators were pretty powerful and had great docs. I wrote a 3D wireframe viewer for the 48g — I got a book on 3D graphics and painstakingly translated an example program in Pascal into the RPN stack language. It was pretty sweet when I got it running. After that I bought a PC and Turbo Pascal, and started studying programming in earnest. I was a decently good programmer by the time I went into the CS program in college.

I went to the University of Washington and got an undergrad degree in CS. It was definitely worthwhile, and I recommend that all programmers should try to get a CS degree if possible.

Linus Torvalds
I didn’t learn programming in school, but mostly on my own reading books and just doing it (initially on a Commodore VIC-20, later on a Sinclair QL).

That said, I think especially University was very useful. Rather than go to an engineering school, I went to Helsinki University, which is pretty theoretical, so there the teaching concentrated not so much on programming (which was just a small part, and which I ended up doing more of "on the side" anyway), but most of the courses tended to be on fundamental concepts and things like complexity analysis. Which can seem boring and even a waste of effort at times, but I think it was useful, and I mostly enjoyed it. And I think I’m probably a better programmer for it.

David Heinemeier Hansson
I learned programming by starting to put together my first web page in HTML. Then I wanted to make some dynamic pieces and picked up first ASP then PHP. After I already knew how to program, I then started on a joint computer science and business administration degree.

Peter Norvig
I took courses in high school and college, but always felt I learned more on my own.

Dave Thomas
During my secondary schooling I took a class in a local technical college on computers. It got me totally hooked: I fell in love with programming, and looked around for colleges offering courses in software. Eventually I went to Imperial College, part of London University. It was only the second year they’d offered a course in software, and it was absolutely marvelous: the staff and students worked together to make the materials better, and everyone learned a lot. The undergraduate course there gave me an incredibly strong background in software development. I stayed on to start a PhD, but got lured away by a startup.

But the overall question is "how did you learn programming?" The real answer to that is "I’m still learning programming." I think any good developer continues to learn throughout their careers. It isn’t just a question of picking up new languages and libraries: good developers also refine their techniques and practices over the years.

Guido Van Rossum
I went to university where they had a big mainframe and there were various computer courses. This was very important for me.

James Gosling
Initially, I was self-taught. I got my first programming job before I went to college. But I’m glad I did. I had a lot of fun. I kept going until I had a PhD.

Bjarne Stroustrup
In university (Aarhus and later Cambridge). The universities taught me much that was useful, incl. most of the bases for my future work. In addition, I learned a fair bit from programming for money - where understanding of real-world problems, correctness, maintainability, on-time delivery, etc. were more pressing than in an educational setting.

Tim Bray
I thought I was going to be a math teacher. The math program at University required a few computer science courses.


Q 2: What do you think is the most important skill every programmer should posses?

Steve Yegge
Written and verbal communication skills. You’ll never make it very far as a programmer in any field unless you can get your ideas across to people effectively. Programmers should read voraciously, practice writing, take writing courses, and even practice at public speaking.

Linus Torvalds
It’s a thing I call "taste".

I tend to judge the people I work with not by how proficient they are: some people can churn out a lot of code, but more by how they react to other peoples code, and then obviously by what their own code looks like, and what approaches they chose. That tells me whether they have "good taste" or not, and the thing is, a person without "good taste" often is not very good at judging other peoples code, but his own code often ends up not being wonderfully good.

But hey, it’s not the only thing. One thing that is very useful, especially in an open source project, is simply the ability to communicate well what you want to do, and how you are going to do it. The ability to explain to others why you do something a certain way is very important, and not everybody has that ability.

That said, in the end there are also the people who just churn out good code. They may not be good at explaining it, and they may not even have great taste, but the code works well. Sometimes you need another person (one that does have that hard-to-define "taste") to maybe massage the code into a form where it’s useful in the bigger picture, but just the ability to write clear code for difficult problems is obviously a fairly fundamental part of any programmer.

David Heinemeier Hansson
A strong sense of value. The ability to ask yourself the question: Is it worth doing what I’m doing right now? So many programmers seem to waste oceans of time on stuff that just doesn’t matter. And not enough on the stuff that does.

Peter Norvig
I don’t think there’s one, but let’s say concentration.

Dave Thomas
Passion.

Guido Van Rossum
Your questions are rather general and hard to answer. :-) I guess being able to cook an egg for breakfast is invaluable.

James Gosling
To be self motivated. To be really good, you have to be in love with what you do.

Bjarne Stroustrup
The ability to think clearly: A programmer has to understand problems and express solutions.

Tim Bray
Ability to prefer evidence to intuition.


Q 3: Do you think mathematics and/or physics are an important skill for a programmer? Why?

Steve Yegge
There is a large branch of mathematics that’s very important for programmers called "discrete math" or "concrete math". It includes disciplines such as probability, combinatorics, graph theory, induction proofs, and other useful tools. I would encourage all programmers to study discrete mathematics to whatever extent they can. Even a little is better than none at all.

As for more traditional math, well, I don’t use it as often, but it comes in very handy when I need it. For instance, I’ve only used calculus once in the past year as part of my job. I had to estimate loads for the peak traffic hour of the day for a service whose load "follows the sun" in an approximate sine curve. The simplest way to make the estimate was to integrate over 1/24th of the curve at a specific time. If I hadn’t known calculus, I would not have known how to make a reasonably accurate estimate.

When I was writing my game, Wyvern, having a solid working knowledge of basic planar geometry was incredibly helpful. And it’s quite common to use algebra and linear algebra on a regular basis. But I rarely use trigonometry or differential equations on the job, and not much calculus either.

I’d say my basic math foundation has made me maybe 5% to 10% better as a programmer. If I knew a lot more math, I’d undoubtedly be a much better programmer than I am today, so I study and practice math several hours a week.

I love physics and I have an ongoing, lifelong quest to try to understand the underpinnings of quantum mechanics. But I’ve never personally found any physics very useful towards my job as a programmer. That would, of course, be diffferent if I were doing something in a physics domain, such as 3D game programming, or certain types of simulation.

Linus Torvalds
I personally think a fairly strong math background is a good thing. I’m not as sure about the physics side, but I’m convinced that understanding math and having a good background in it helps you to be a better programmer. If only because the mental models are similar - you can build up any kind of set of rules you want, but it should be self-consistent.

David Heinemeier Hansson
Not at all. At least not for the kind of business programming needed for web applications. I consider it much more important that someone is a good writer.

Peter Norvig
Yes. Many ideas are inherently mathematical: induction, recursion, logic, etc.

Dave Thomas
Maybe. But, to be honest, I haven’t seen much of a correlation either way between these types of discipline and good software developers.

However, I have seen a strong correlation between people who have some music in their background and programming skills. I have no idea why, but I suspect that some of the areas of the brain that make someone musical also make them good at software development.

Guido Van Rossum
Math, yes (for some parts; I don’t care for differential equations, but algebra and logic are important). Physics, I don’t think so except it’s always useful to be interested in many different things.

James Gosling
Yes! They teach you logic & deduction... To have an analytical eye. And there’s no replacement for mathematics when it comes to analyzing algorithms.

Bjarne Stroustrup
Depends on the programmer and the programming tasks. Some forms of math are frequently useful; physics less often so, but then learning physics is one of the best ways of learning practical math.

Tim Bray
In my case, I’ve almost never used my university-level math to support my programming.


Q 4: What do you think will be the next big thing in computer programming? X-oriented programming, y language, quantum computers, what?

Steve Yegge
I think web application programming is gradually going to become the most important client-side programming out there. I think it will mostly obsolete all other client-side toolkits: GTK, Java Swing/SWT, Qt, and of course all the platform-specific ones like Cocoa and Win32/MFC/etc.

It’s not going to happen overnight. It’s very slowly been going that direction for ten years, and it could well be another ten years before web apps "win". The tools, languages, APIs, protocols, and browser technology will all have to improve far beyond what you can accomplish with them today. But each year they get a little closer, and I’ve finally decided to switch all my own app development over to browser-based programming from now on.

Microsoft and Apple definitely don’t want this to happen, so a necessary first step will be for an open-source browser such as Firefox to achieve a dominant market position, which will in turn require some sort of Firefox-only killer app. (A killer app would be something like iTunes, something that everyone in the world wants to use, badly enough to download Firefox for it.)

Linus Torvalds
I don’t think we’ll see a "big jump". We’ve seen a lot of tools to help make all the everyday drudgery easier - with high-level languages and perhaps the integration of simple databases into the language being the main ones. But most of the buzz-words have been of pretty limited use.

For example, I personally believe that "Visual Basic" did more for programming than "Object-Oriented Languages" did. Yet people laugh at VB and say it’s a bad language, and they’ve been talking about OO languages for decades.

And no, Visual Basic wasn’t a great language, but I think the easy DB interfaces in VB were fundmantally more important than object orientation is, for example.

So I think there will be a lot of incremental improvements, and the hardware improvements will make programming easier, but I don’t expect any huge productivity help or revolutions in how people do things.

At least not until you start approaching real AI, and I don’t think real AI is going to be anything you will ever "program".

David Heinemeier Hansson
I try not to predict the future. I’m not a big believer in fortune telling. The best way to predict the future is to implement it.

Peter Norvig
Large-scale distributed processing.

Dave Thomas
The next big thing in computer programming will be eclipsed by the next–next big thing in programming, and so on, and so on. I’m kinda tired of the endless search for the big things, because while doing it people tend to forget about the real issues: getting the fundamentals right. We need to get a whole lot better at talking with our customers, focussing on delivering value, and taking pride in what we do. A developer who can do these things can deliver great software with any tool set, and won’t need to worry about tracking the fads and fashions.

Guido Van Rossum
Sorry, I’m not much of a crystal ball person. I predicted CGI about 5 years after it had been invented. :-)

James Gosling
The two issues I’m most concerned about now are coping with parallelism and complexity.

Bjarne Stroustrup
I don’t know, and I don’t like to guess.

Tim Bray
No idea.


Q 5: If you had three months to learn one relatively new technology, which one would you choose?

Steve Yegge
I do happen to have 3 months (part-time), and I’m spending it learning Dojo (http://dojotoolkit.org) and advanced AJAX and DHTML. I’m learning it by writing a fairly ambitious web application. Dojo’s really cool, and I’m sure it will only improve with time.

Linus Torvalds
Hmm. I’d really love to do FPGA’s, but I’ve always been too busy to really sit down and start learning. I love the notion of playing with hardware: it’s obviously one of the reasons I ended up doing operating systems, since that (along with compilers) is about as close as you can get to playing with the hardware, without actually designing or building it yourself.

David Heinemeier Hansson
Cocoa programming for the Mac.

Peter Norvig
I’d like to know Javascript better. Also flash.

Dave Thomas
If "new" means "new to Dave Thomas" then I think I’d take intensive piano lessons.

If "new" means technology stuff, then I guess I’d choose technologies related to accessibility for people with disabilities.

Guido Van Rossum
Snowboarding.

James Gosling
For fun, I’d catch up on the latest in 3D rendering. I’d probably write a photon-map renderer.

Bjarne Stroustrup
There are very few things of any importance that you can learn in three month. I think you must be thinking of training in a well established field.

Tim Bray
Security, encryption, digital signatures, identity, etc. It’s a big problem for me that I’ve never learned this stuff.


Q 6: What do you think makes some programmers 10 or 100 times more productive than others?

Steve Yegge
I think if you pause to consider why not all atheletes are equally good, you’ll have your answer(s). Thomas Edison has a relevant quote about genius that might also provide you some clues.

Linus Torvalds
I really have no idea. I think some people are just better able to concentrate on the things that matter, and I think a lot of it is just doing it. Most of the really good programmers I know started doing it fairly young.

David Heinemeier Hansson
The ability to restate hard problems as easy ones.

Peter Norvig
The ability to fit the whole problem into their heads at one time.

Dave Thomas
They care about what they do.

Guido Van Rossum
Genetically different brain structure.

James Gosling
They think about what they do. They don’t rush in and slap things together. They have a holistic picture of what is to be built.

Bjarne Stroustrup
First a general lack of professionalism and adequate training. that sets the base level too low. Secondly, some people have a combination of "smarts" (ability to think clearly and get to the heart of things), experience, and knowledge of tools. Programming leaves more scope for that because it is a combination of theory and practice - neither of which is much use without domain knowledge.

Tim Bray
The surprising variability of the human mind.


Q 7: What are your favourite tools (operating system, programming/scripting language, text editor, version control system, shell, database engine, other tools you can’t live without) and why do you like them more than others?

Steve Yegge
OS: Unix! I use linux, cygwin, and darwin all about equally often now. You just can’t beat it for productivity tools. Every programmer should learn how to use every tool in /bin and /usr/bin.

Scripting language: Ruby. I’m proficient with just about every major scripting language out there: Perl, Python, Tcl, Lua, Awk, Bash, and others I’m forgetting. But I’m really lazy, and Ruby’s by far the easiest, so it’s a match made in heaven.

Programming language: I don’t have a favorite; I think they all suck. I tend to prefer Java because it’s a strong, portable platform with good tools and good libraries. But the Java language will evolve or die; it’s not good enough as-is to hold the lead indefinitely.

Text editor: Emacs, because it’s the best thing out there today.

Version control: SVN. Perforce is better, but it’s very expensive.

Shell: Bash, because I’m too lazy to learn a better one.

Database engine: MySQL, of course. Nothing else comes close.

Others: I find the GIMP invaluable, and also maddeningly unintuitive. I’ve been using it for years and can still barely do anything with it. But I couldn’t live without it, ironically enough.

Firefox is becoming an increasingly critical part of my tools lineup. I feel suffocated when I’m forced to use IE or Safari.

Note that all these tools (Unix, Emacs, Firefox, GIMP, MySQL, Bash, SVN, Perforce) have something in common: they’re extensible; i.e., they all have programming APIs. Great programmers learn how to program their tools, not just use them.

Linus Torvalds
I actually don’t end up having that many tools I work with, and for the many of them I have spent some time of my own to just make them work for me. The OS part is clearly the biggest one, but I’ve obviously also written my own version control system (git), and the text editor I use (micro-emacs) I’ve ended up customizing and extending upon too.

Other than those three parts, the only thing I care deeply about is my email reader. I use "pine" - not because it’s necessarily the greatest email reader ever, but because I’m used to it, and it does what I need it to do with a minimum of fuss.

David Heinemeier Hansson
OS X, TextMate, Ruby, Subversion, MySQL. That’s the combo currently keeping me happy. I like tools that exhibit good taste and a focus on the stuff that matters.

Peter Norvig
I dislike all three major OS - Windows, Mac, Linux. I like Python and Lisp. Emacs.

Dave Thomas
I switched to Macs a couple of years ago after being a Linux person for more than 10 years. The tools are not necessarily better, but they don’t have to be sharpened or maintained as often, which lets be concentrate on just using them.

I'm not a great believer in single tools: I tend to switch around quite frequently just so I can get experience with as many tools as possible. Right now I’m using OSX, Emacs, TextMate, Rails, Ruby, SVN, CVS, Rake, make, xsltproc, TeX, MySQL, Postgres, and a whole lot of small productivity aids. Who knows what I’ll be using next year.

Guido Van Rossum
Unix/Linux, Python, vi+emacs, Firefox.

James Gosling
These days I live in NetBeans. It does everything I want, very cleanly simply and efficiently. It’s the nicest environment I’ve ever lived in.

Bjarne Stroustrup
Unix, sam (a very simple text editor), and a good C++ compiler, of course.

Tim Bray
I like Unix-like operating systems, dynamic languages like Python and Ruby and statically-typed languages like Java (in particular the Java APIs), Emacs, whatever, bash, whatever, NetBeans.


Q 8: What is your favourite book related to computer programming?

Steve Yegge
Man, that’s a tough one. Maybe "Gödel, Escher, Bach: an Eternal Golden Braid" (Hofstadter)? Although it’s not strictly about programming. If you specifically mean "favorite book about programming", then maybe SICP (mitpress.mit.edu).

Linus Torvalds
Heh. When I read these days, I tend to either read fiction, or non-computer-related stuff (oldie but goodie: "The Selfish Gene" by Richard Dawkins).

When it comes to programming, the only real programming book that comes to mind is actually the classic Kernighan & Ritchie "The C Programming Language" book, because it’s such an incredibly useful book while being so very readable and short. Considering that you can basically learn one of the most important programming languages of our times from it, the fact that it’s thin and readable is just a wonder.

That said, many other books I enjoyed a lot were not about programming per se, but about computer architecture and hardware. There’s obviously Patterson & Hennessy’s computer architecture book, but for me personally perhaps even more Crawford & Gelsinger’s "Programming the 80386?, which was what I used when I started with Linux.

For similar reasons, I have a soft spot for Andrew Tanenbaum’s "Operating Systems: Design and Implementation".

David Heinemeier Hansson
I like Extreme Programming Explained for its rejection of common thinking about programming practices and Patterns of Enterprise Application Architecture for striking the right balance of abstract and concrete.

Peter Norvig
Structure and Interpretation of Computer Programs

Dave Thomas
It depends on what you mean by "favorite." Probably the best written book I’ve read in the area is IBM’s "IBM/360 Principles of Operation."

Guido Van Rossum
Neil Stephenson’s Quicksilver.

James Gosling
Programming Pearls by Jon Bentley.

Bjarne Stroustrup
K&R.

Tim Bray
Bentley’s Programming Pearls


Q 9: What is Your favourite book NOT related to computer programming?

Steve Yegge
Just one book? You’re asking for the impossible. There are too many great books out there to choose just one.

My favorite books that I’ve read this month are "Stardust" (Neil Gaiman) and "The Mind’s I" (Hofstadter/Dennet).

My favorite writers are Kurt Vonnegut, Jr. and Jack Vance.

Linus Torvalds
Well, I already mentioned the Selfish Gene by Dawkins. On the fictional side, there’s just a lot of books I’ve read and enjoyed, but few I’d say were my "favourite" one. I tend to not often re-read the books, and the selection would change over time. It’s mostly science fiction and fantasy, eg "Stranger in a Strange Land" by Heinlein was my favourite one as a teenager, but it’s a bit less clear-cut for me these days..

David Heinemeier Hansson
1984, George Orwell.

Guido Van Rossum
Neil Stephenson’s Quicksilver.

James Gosling
Guns, Germs & Steel by Jared Diamond

Bjarne Stroustrup
It changes over time. Currently O’Brian’s Aubrey/Maturin series.

Tim Bray
One Day in the Life of Ivan Denisovich


Q 10: What are your favourite music bands/performers/composers?

Steve Yegge
Favourite genres: classical, anime soundtracks, video-game music
Favourite composers: Rachmaninoff, Chopin, Bach
Favourite performers: David Russell (classical guitar), Sviatoslav Richter (piano)
Favourite anime OSTs: Last Exile, Haibane Renmei

Linus Torvalds
I'm actually not very much into music, but when I listen to it, I tend to listen to various classic-rockish things, ranging from Pink Floyd to the Beatles to Queen and The Who.

David Heinemeier Hansson
I like a lot of genres. Beth Orton, Aimee Mann, Jewel, Lauryn Hill. Actually, all those examples would fit under Girls with Guitars ;).

Guido Van Rossum
Philip Glass.

James Gosling
I tend to like folk musicians: Christine Lavin, Woody Guthrie, Pete Seeger...

Bjarne Stroustrup
Band: The Dixie Chicks. Composer: Beethoven.

Tim Bray
Read my blog.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Postscript

How I found this: I was reading this post by Jeff Atwood, titled "Linus Torvalds, Visual Basic Fan" where the source article he linked to was: "STIFF ASKS, GREAT PROGRAMMERS ANSWER". But that link was dead, and doing a search didn't find any trace of it anywhere on the net. So I resorted to an archive.org search and sure enough, up popped this incredible blog post by Jaroslaw Rzeszótko.

Due to it no longer being available on the net, I thought it should reposted again so others can enjoy reading it. I requested permission from the original author to do this, and he happily obliged - thanks again Jaroslaw!

Follow @dodgy_coder on Twitter

Read a Chinese translation of this blog post  << Thanks to the guys at CoolShell.cn for this!

Read a Turkish translation of this blog post  << Thanks to Seval for this!

Old school developers - achieving a lot with little

Ken Thompson

I was reading through bits of the excellent Coders at Work book by Peter Seibel and found it interesting that the (what I'd call respectfully) old school developers, such as Ken Thompson, Joe Armstrong and Jamie Zawinski use hardly any modern tools and techniques while developing software.

Ken Thompson was the designer of the B programming language (the precursor to C) and also the Go programming language (with Rob Pike). He also worked alongside Dennis Ritchie to develop the C programming language and the original Unix operating system while working at Bell Labs. After designing the UTF-8 method of character encoding on a placemat in a New Jersey diner, he worked overnight to implement full UTF-8 support in Bell Lab's Plan 9 operating system. Regarding his programming style, he debugs only via printf statements, hardly ever uses unit tests, starts his projects by designing the data structures and then works bottom up, with throwaway test stubs.

Joe Armstrong

Joe Armstrong developed the Erlang programming language and the open source Open Telecom Platform (OTP) framework for Ericsson. When designing software he prefers to rigorously document as much as possible up front before starting to write code, especially for difficult projects such as those involving real-time networking protocols. He uses prototypes to solve the hard problems first, and for debugging, just uses print statements. He is a critic of Object Oriented Programming, and favours functional programming languages like Haskell. He never uses an IDE, preferring just Emacs and the command line (no mouse required).

Jamie Zawinski worked in MIT's AI lab with Lisp, then moved onto leading the development of Lucid Emacs, also in Lisp, which later became known as XEmacs. After this he joined Netscape and worked on the front-end for the Unix version of Netscape Navigator, and later led the development of Netscape Mail (both projects were in C). He too prefers to just use print statements to debug his code. His process is either to write code top down or bottom up, let the code evolve naturally, then refactor it when necessary. During development he hardly ever uses unit tests, believing it slows things down - he thinks there's a lot to be said for getting the code right first time. In his view, its a matter of priorities, "do you want this to be good software or do you want it to be done next week - pick one because you can't have both".

Jamie Zawinski

So what tools and techniques do you actually need to be a great programmer? Are these modern techniques of TDD, BDD, Scrum, Agile, Design Patterns, XP etc. just window dressing or do they serve a higher purpose? Is it just a fact that a gifted programmer will always find a way to be a great programmer, no matter what tools he or she works with?

My own view is that some level of TDD and a reliance upon a decent set of unit tests is invaluable. Maybe then these modern techniques should just be seen as advances to make our job a little easier and more productive, especially for those who are not a genius-level developer, like these guys.

Follow @dodgy_coder

Subscribe to posts via RSS