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.
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?
If you liked this, click here to receive new posts in a reader.
You should also follow me on Twitter here.
by Ville Laurikari on Monday, April 12, 2010
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?
If you liked this, click here to receive new posts in a reader.
You should also follow me on Twitter here.
