Do You Write Legacy Code?

by Ville Laurikari on Wednesday, September 8, 2010

In his foreword to Working Effectively with Legacy Code by Michael C. Feathers, Robert C. Martin says:

Legacy code. The phrase strikes disgust in the hearts of programmers. It conjures images of slogging through a murky swamp of tangled undergrowth with leaches beneath and stinging flies above. It conjures odors of murk, slime, stagnancy, and offal. Although our first joy of programming may have been intense, the misery of dealing with legacy code is often sufficient to extinguish that flame.

Dilbert.com

Besides serving as inspiration for poetic descriptions of wetlands and humorous sequences of drawings, legacy code is also something you don’t want in your Emacs. But how can you prevent it from getting there? At what point does code turn from “perfectly good” or at least “I guess it’s OK” into “legacy crap”? We need to define what “legacy code” is.

Many people will characterize legacy code as simply old, but that’s not a very practical definition. Good code doesn’t turn into legacy code on a rainy Tuesday afternoon at 2:17pm. A better definition gives us some clues on how to prevent code from becoming legacy code. You can’t stop time.

Perhaps legacy code is a feeling. It’s the feeling that the code is too hard to approach, risky to change, and difficult to understand. This makes for a slightly better definition, because it suggests some things to avoid (don’t write crappy code, duh!). However, basing a definition like this on feelings is a bit… scary.

In the book, Feathers gives a very simple definition:

To me, legacy code is simply code without tests.

This is a pretty good definition. Tests make the code simpler to approach, less risky to modify, and easier to understand. Tests protect against the very things that make legacy code legacy.

With this definition, we arrive at a shocking realization: someone in your team could be writing legacy code right now.

Do you write legacy code?

{ Comments on this entry are closed }

If you liked this, click here to receive new posts in a reader.
You should also follow me on Twitter here.

Why Apple Doesn’t Want Your App

by Ville Laurikari on Monday, April 12, 2010

Post image for Why Apple Doesn’t Want Your App

So you make an iPhone app, and it doesn’t enjoy the success you think it deserves. Or you make an app, and you create a technology framework on the side, and they ban your framework, and your app and framework don’t enjoy the success you think they deserve. Here’s why.

First, a detour to clarify what Apple makes money from. For perspective, let’s look at Microsoft first.

Microsoft is, and has pretty much always been, in the business of selling Windows. Microsoft wants PCs to be cheap, so they can sell more Windows. The whole PC and peripherals market is fiercely competed and the profit margins for hardware vendors are really low. That’s been working out nicely for Microsoft, since most PCs still ship with a version of Windows included, and Windows is making tons of money.

Microsoft is also in the business of selling Microsoft Office. In 2008, Microsoft made as much money with Office as it did with Windows. Kind of like the fax machine was (and still is in some parts of the world), Office is the standard method of information interchange in the business world. Just like the fax machine, you need Office because everyone else has it, too.

Apple, on the other hand, is in the business of selling hardware. Despite their recent high-profile focus in the iPhone OS software, Apple is very much a hardware company.

So let’s get this straight: Apple is not making a lot of money off the App Store. Apple is not even trying to make a lot of money off the App Store.

Apple wants apps to be a cheap commodity. When there are a lot of cool apps around, and they cost next to nothing, it really makes you want to go buy an iPhone, doesn’t it? Useful, cheap apps sell more iPhones. Microsoft is the opposite: cheap hardware sells more Windows.

In this light, I find it strange how Apple is conducting some of their business towards the community of independent software developers. The latest ban on using anything but Objective C, C, C++ for native apps, for example, strikes me as quite strange. By which I mean it strikes me as completely idiotic. Banning programmers’ favorite tools is stuff which makes talented developers call it quits and stop working on the iPhone platform. How can that possibly be in Apple’s business interests?

Many iPhone developers seem to be driven by the “publish an app and get rich quick” myth. However, the app market is fiercely competed. In order to make any significant money on the App Store, your app must be really good, one of the first of it’s kind (if not the first), and you must be lucky. This is App Store poker. It’s like trying to win the World Series of Poker by entering a satellite freeroll. It can happen, but I’m willing to be it won’t happen to you.

Is App Store poker enough to maintain a steady influx of apps to iPhone OS? Oh yes, it is. It is more than enough. Like with their hardware, Apple wants the apps to be about quality, not quantity. Robert Scoble says:

So, what does Apple need? Is it more apps? No way. At 130,000 apps Apple already has enough apps to keep a sizeable lead for years over its competitors like Google’s Android OS.

No, what Apple needs is better quality apps. So, does Apple care about templated apps or ones developed in Flash or some other cross-device language/system? No way.

Apple doesn’t want your app because your app sucks. Probably. Statistically, anyway. Most apps aren’t anything special, why should yours be any different?

{ Comments on this entry are closed }

If you liked this, click here to receive new posts in a reader.
You should also follow me on Twitter here.

Is Your Regex Matcher Up to Snuff?

March 16, 2010

Did you know that your regex matching library may suck? Most libraries do, in certain circumstances, suck exponentially. This came to me as a great suprise when, a long time ago in the olden days before Google, iPods, and salmon skin leather, I was researching regex matching engines hoping to find a good one [...]

10 comments Read the full article →

Metric of the Month: Duplicate Code

February 10, 2010
Thumbnail image for Metric of the Month: Duplicate Code

There are few hard and fast rules in software development, but this one comes close: don’t copy and paste code. Keeping multiple copies around within the same code base is almost never a good idea.
Question is, do you have duplicate code in your code base? How much would you be willing to bet?
Recently [...]

6 comments Read the full article →

Should You Be a Generalist Or a Specialist?

January 15, 2010

When I was a young student, I had a fashionable infatuation with martial arts.   One day at the dojo I was busy practicing a particular punch to the side of the neck.  The teacher watched my repeated fumbling for a while, and finally pulled me aside and gave me one of the best [...]

26 comments Read the full article →

Building High Performance Software Teams

December 24, 2009
Thumbnail image for Building High Performance Software Teams

A matrix organization allows you to build teams with a high degree of specialization and top-notch skills, plan your resourcing easily, and encourages sharing knowledge between product teams. A matrix organization is great. Except that it’s not, not for developing software.
It’s not great when coders don’t do any testing because it’s the QA department’s [...]

14 comments Read the full article →

The Silver Bullet That Wasn’t

December 8, 2009
Thumbnail image for The Silver Bullet That Wasn’t

I have a confession to make. I occasionally fall prey to a most basic mistake: I think a tool will solve a problem before I even understand the problem.  Here’s what happened this time…
Like any company, we have an intranet. Ours is a motley collection of internal websites and tools: we have a [...]

9 comments Read the full article →

If Your Code Crashes in Production, Does it Make a Sound?

November 18, 2009
Thumbnail image for If Your Code Crashes in Production, Does it Make a Sound?

Meet Frank. Frank works as a product manager at Faxes-R-Us. He’s finishing up a presentation on their latest fax machine model: FRU-1221i with integrated Twitter and Facebook support. This one will sell like hot cakes.
Frank’s presentation is due tomorrow, and he’s now trying to include pictures on some of the slides. [...]

4 comments Read the full article →

The Three Doors of Type Systems

November 11, 2009
Thumbnail image for The Three Doors of Type Systems

Every so often, I get drawn into a discussion about the merits of static typing (Java, C, C#, ML) versus dynamic typing (JavaScript, Python, Ruby, Scheme). Many programmers seem to be firmly in one camp or the other. But somewhere in between, there’s a third door. Let me explain…
I hate dynamic typing.
Dynamic [...]

4 comments Read the full article →

Hashed Bits becomes Hacker Boss

November 9, 2009

I decided to change the name of this blog to something more descriptive and less “meh”. This blog is about developing software and managing development teams. That is, about hacking, and about being a boss. Frequently at the same time.
It is likely that RSS subscribers will see old posts coming up [...]

Read the full article →