Here's an example of how I've used it:

#if TARGET_CPU_ARM
	// Device will hit external server over cell network
	NSString const *ROOT_URL = @"http://www.external-site.com";
#else
	// Simulator will hit local server over LAN
	NSString const *ROOT_URL = @"http://localhost:8667";
#endif

This kind of tweaking is particularly important when the device itself can not participate on the local network, but needs to access some kind of external environment (or proxy server). Conversely, targeting the simulator to use a local 'development' server is often faster when deploying and debugging issues in your application, particularly if you are developing the server component in tandem.

Another example involved certain audio playback features which work fine on the device, but run into hiccups running on the simulator. Since in this case the functionality is not critical to test, I ignore it in the simulator.

• Amazon EC2 is offering Windows on EC2, with the pricing at $0.125 per hour for a small instance running Windows Server (as compared to $0.10 for a Linux instance). You can run SQL Server Express at no extra charge. The SQL Server Standard smallest instance (Stadard Large) rings in at $1.10 per hour, however, which ain't such a good deal.
• Microsoft's Azure Services Platform. It's still in community evaluation mode, but there is one thing that is already clear about it: it's as confusing as all git out. One of the advantages of Amazon's services like S3 and EC2 is that they are simple and can form the building blocks for other applications and services.

If I'm provisioning a web application, I'm pretty comfortable thinking in terms of virtual servers or instances. Not sure how to think about scaling and cost with Azure. I think MS would have done better to start out with a KISS approach to drive adoption. Time will tell if their "it can cure cancer" approach will work out.

Granted, that's only one location, but based on all of the annecdotal evidence I have, as well as how well the T-Mobile folks were trained to deal with the iPhone switch (not only on my request, but on my wife's similar call last week) I am expecting some pretty strong numbers form Apple tomorrow.

I'm also expecting decent G phone numbers for Q4, but I'm not sure how well they'll hold up later.

Update: It looks like Apple's Q4 iPhone sales topped 6.9 million, about 800,000 units more than RIM's 6.1 million in the equivalent period, beating most analyst expectations by a mile.

Interesting discussion on this over at Daring Fireball (of course) as well as a piece on Fortune on traditional analysts versus bloggers on Apple sales and earnings.  The bloggers got the iPhone numbers better than the analysts, but everyone missed on mac sales.

Server-on-demand providers like Amazon's EC2, Joyent,
and others have reduced the capital necessary to launch scalable,
server intensive businesses. Google has just launched a similar
on-demand service, and companies like RightScale and CohesiveFT are building mature businesses around managing EC2 configurations.

...

Facebook applications are just the most extreme example of business initiatives that can be scaled on demand from $70/month on one EC2 server to $10,000/month on many dozens of servers running web, application and database server clusters and farms. Compare that with the old school of investing in a large data center with a significant fraction of the hardware and bandwidth that you might need if your business is a success. What used to cost $100k in capital can now be done with just a few hundreds of dollars.

...

And it's all possible as long as you are using a unix variant - Linux for the most part - to power your apps. So there is a whole class of companies out there using Linux that can out compete their Windows-using rivals - again, the capital they need to launch is much smaller because of cloud computing. That means Linux will win among the class of young entrepreneurial businesses that are so vital to the US economy.

It seems that Microsoft has spotted this gaping vulnerability and is seeking to close it. From the Amazon announcement on support for Windows on EC2:

Starting later this Fall, Amazon Elastic Compute Cloud (Amazon EC2) will offer you the ability to run Microsoft Windows Server or Microsoft SQL Server.

...

Customers will only pay for as much or little as they actually use; of course the actual price will be higher than Linux-based instances, due to the cost of Windows licenses. We’ll announce specific pricing when we make the service broadly available later this Fall.

Combine this with the announcement earlier this month that you could officially run Oracle on EC2 (though you still have to license it rather than pay as you go), and it's clear that commercial software vendors are feeling the preasure of SaaCS (Software as a Commodity Service).

Jason Fried from 37Signals spoke yesterday at the ITA "Speaking of Success" event, about the history of 37Signals, their philosophy and culture, and the critical business decisions they've made to get them where they are today.

The software biz is fundamentally broken. Too many products fail because of the obsession of adding more and more, and trying to do too much.

Jason went on to say that the approach of adding more and more only works for companies that have lots of money and lots of time, but that for the average company the main goal should be to build something that is "good enough," get it out to the users, and improve the design based on their feedback. The challenge of which features to include, and which to say "No" to, is covered well in the "The Innovator's Dilemma," which he said "everyone in this room should have read." The book resonates the core philosophy of 37Signals, which is evident from their blogs, their book "Getting Real," and the design of the Rails framework. As an example of the "Good Enough" philosophy, Jason used his laptop and its basic webcam to stream the Q&A session out over justin.tv and send out a text to the 37signals Twitter group. "The quality probably isn't that great, but its good enough," and with that quick setup he had now broadened the audience by 1,000 users or so. (I searched for the video archive at justin.tv, but didn't find it yet.)

"Our products do less than the competition"

While this quote isn't new, I still find that its worth digesting, particularly as it relates to product planning and product design. I'm a big fan of Agile and iterative development, and the idea that we don't have to have the full product requirements solidified before we can get started. I like to take a product vision to market quickly, improve on the design, and add features as their necessity becomes more clear.

I found that the things that Jason mentioned that resonated with me the most were closely in line with what I liked about DHH's Q&A session at last week's WindyCityRails conference in Chicago. I think a big part of 37Signals success is due to the fact that its two primary partners are totally on the same page.

Working at a consulting company like Pathfinder presents two major challenges in this area. First, the customer most likely doesn't know anything about Agile, nor do they really care about it. They want to see results and the details of how those results come about may not be something they care to explore. Secondly, our customer cares deeply about the design of the product, and the features that absolutely HAVE to be in for the release. The idea of going to market with "less" is a difficult concept to swallow. I've found that the more the design process explicitly involves the actual end user, the easier it is to investigate the importance of a given feature, ask them about it, prototype it, and figure out if its going to make things better for them. Conversely, if the end-user isn't closely involved in the design process, feature priority is more of a guess, and out of fear and lack of certainty features are included because "yeah, we might need that too". So when the question is raised, "Which is a higher priority, feature A, or feature B?", the answer is often an unequivocal "BOTH!"

On this point Jason had two elegant explanations that I hope to draw from. First, doing "less" really means covering the "essentials" of what is needed, and doing those "fewer" things better. He mentioned their products as being like a tool, with a specific, focused purpose.

"A hammer is a tool, its very focused, and has a clean, simple interface."

It strikes me as a perfect example of clarity and focus, because no one is screaming for a hammer that measures distance, cuts wood, or tightens nuts & bolts. Its intended use is clear, it doesn't need to do more than that.

"We like to think of ourselves as curator's of the product. A curator at a museum chooses which pieces of Art should be included in the collection. They say "No" to many things. A building full of lots of Art that isn't carefully selected isn't a museum, its a warehouse"

I've certainly seen applications that were a "warehouse" of features in need of greater focus and "tasteful selection" for what should be included. My mission now is to find a better way to deliver the message that "less is more," and that in most cases, its better to get the application out to the users quickly, and leave room to iterate and improve on the design, than it is to try to build and release the perfect product all in one shot.

How do you deal with this issue in your day to day work? What effective techniques have you found for bringing clarity to the design of a product?

Photo Credit:
Darren Hester
under a Creative Commons Attribution License

Monopsony - the market condition that exists when there is only one buyer.

We all have heard the term "monopoly" and even know a little bit of what it means - a market where there is only one seller. But the related term "monopsony," a market where there is only one buyer, is not as well known and it's dangers not as well understood.

Certainly both monopolies and monopsonies will reduce competition, innovation and consumer choice, but they further constitute a big risk for the sellers. For businesses on the seller side a monopsony can be the kiss of death. Just ask Walmart's suppliers how good it's been for them.

Not all monopsonies are as obvious or as overtly damaging to suppliers as that of Walmart, but Apple's iPhone and iTunes appstore looks like a benign monopsony. A monopsony in that although the iphone consumer is the ultimate buyer, Apple determines what is permitted in it's appstore, and benign in the fact that Apple hasn't flexed that restrictive muscle more than a few times.

But for the business launching an iPhone app this monopsony - benign or not - presents a real concern, a real business risk. What happens if Apple decides to compete in your space? The evidence on what happens right now is not encouraging. Take the recent example of the podcasting application that was excluded from the AppStore. The reason for it's exclusion?

Since Podcaster assists in the distribution of podcasts, it duplicates the functionality of the Podcast section of iTunes.

That's the desktop version of iTunes versus an application on the iPhone that you can use without a PC or Mac. Presumably, if people don't have to use iTunes to get their podcasts, then there's less reason to use iTunes and consequently less chance that they'll actually spend money with Apple.

Since you only find out whether your application will be approved in the last step, i.e. after all of the hard development work has been done, that's a lot of risk to take. How to minimize it? One approach to minimizing risk might go as follows:

• Distribute an application with an initial pretty minimal set of functionality. Quick to produce and get the yes/no appstore answer.
• Design your application so that it supports and embedded language runtime, such as Ruby or JavaScript, and a capability to push additional modules of functionality to the application independent of the appstore.
• Extend your application using the above distribution mechanism. The only time you'll have to push a new version of the app is when the underlying iPhone platform changes and you'd like your embedded layer to take advantage of new features.

Of course Apple is known to have a "kill switch" to turn off apps that have already been downloaded to a phone, so even the above approach may not insulate you from risk. So, if you are developing for the iPhone, have a care on whether your application will run into competition from Apple. You may find your application unceremoniously rejected or killed.

Update: Looks like Apple has  banned another application, MailWrangler, that competes with it's own email application.

If you can dream it, you can do it.

-- Walt Disney

You have a great idea, an idea that is going to transform an industry. You've turned a venture capitalist's head with your presentation and now you just need a software development firm to translate your vision into reality. This is where the trouble starts.

If you move in startup VC circles, you see enough of these deals go sideways or never get off the dime. Investors see hundreds of thousands or millions of dollars plowed into software development without a usable product or service coming to light. Fingers are pointed; tears are shed. For every success there are a half dozen failures. Why is that?

In my experience it all comes back to that word, "vision" as in "translate your vision into reality." What the heck is vision? If you've ever cracked a book on software project management (or just general project management), there's usually a section about having a project charter and a vision statement. As a young developer I would wince and turn to the next chapter. After all, I thought, isn't vision the same thing as what you're going to build? Isn't scope or, more basically, a list of things your are going to build, the same thing as "vision?" Why blather on in consultant speak about vision statements when a more concrete and practical project description could be had?

And this is where the trouble starts. If you don't have a clear idea of what you are building but have a bright and effective development team, you may still come up with a plausible list of things to build. You'll crank along, iteration after iteration, turning out software -- that is, after all, what a good development team does -- but you are likely not developing the right software.

Poor Vision: Are We Building a Spreadsheet or a Word Processor?

Poor vision is not the same thing as bad vision. You may have a very clear idea of what you want to build but it may suck, like the company that wanted to build a laptop software management suite based on cc:Mail in the face of the burgeoning web. No, poor vision means that you have a poor or incorrect notion of what you want to build.

Hopefully most of these ambiguities have  been cleared up by the heartless venture capitalists, but just in case, let's do an exercise. Answer the following questions about your proposed software:

• Do you know who your customers are? Not just traders, but day traders above a certain trading volume in options and futures.
• What is your value proposition? Why would someone actually use your software? Don't use "wonderful" or "joy" in your description.
• What specifically will your users be doing with your application? Don't use abstract verbs like "collaborate" to describe their actions.

If you can't put together a one or two paragraph description of your software that answers these questions, you just have a cool idea, not a vision. As a friend of mine likes to say, "that's crap...it's not something you can develop software from."

At this point you may be scratching your head and wondering what kind of idiot would launch into development without a good vision. It seems so obvious. The truth is that coming up with game changing business ideas is hard work, and in conceptualizing the business opportunity, you may fail to articulate a precise vision. Whatever the reason, software project launching with poor vision is all too common.

Poor Vision: The Version 2 Problem

There are other types of vision problems beyond a lack of clarity and focus. One common case is the "version 2 problem." This is where the stakeholder just focuses on the "new" things that are to be present in version 2 and ignores all the hard work that has to be recapitulated just to get them to where version 1 was. Asking the question "what are we building?" should lead you to realize that what the stakeholder is expecting is enhancements to version 1, not a complete rewrite or redesign. The why are they talking about a "version 2?" Ideally this should lead to a discussion that clarifies vision and expectations.

Poor Vision: Integrating the Wrong Systems

Poor vision isn't just limited to custom software development. Sometime the job calls for customization or integration of existing software packages. The vision problem here is that sometimes stakeholders will look at the feature list of an application and the fact that it has an API and conclude that tweaking the beast into your ideal solution is a piece of cake.

Here the solution is simple: make the stakeholders get their hands dirty. Force them to use the system in question -- no, vendor demos are not enough -- to accomplish some non-trivial tasks. This exercise, combined with an analysis of the power and expressiveness of the API, should resolve any vision dissonance.

The Perils of Agile Development

Poor vision is a problem that can strike any project and any method ("methodology" is the study of methods, right?). Agile development, however, is especially susceptible to it's chaotic effects. Why is that? The great strength of Agile development is that teams start developing and delivering software right away so that the client-developer feedback loop can operate early and often. If that feedback is useless -- as it is when you have poor vision -- the Agile development process can turn into a meandering mess, with features being scrapped, redeveloped and re-redeveloped.

How do you avoid this trouble? Simple: if your vision is poor, don't develop software.

Software development is a surprisingly expensive way to do product definition.

Waterfall, by comparison, is marginally better in this regard (but worse in most others), since the right thing to do in the face of poor vision is to not develop software until that vision has been clarified, and waterfall is excellent at not developing software until pretty late in the project.

That's not to say that you can't get stung by poor vision in waterfall projects (and stung by a number of waterfall's other shortcomings), but you've got more of a chance to catch the problem before expensive developer teams are deployed.

Fixing Poor Vision: Product Definition

The best way we've found of fixing poor vision is by going through a product definition phase. It can still be iterative and agile, so don't worry that you're slipping into a waterfall requirements phase. Just do some of the user research and product conceptualization up front. Use wire-frames and the like rather than code to spitball ideas and narrow in on a definitive product concept.

I'll have more to say on product definition in subsequent posts. For now, I hope I've convinced you of the importance of having a clear vision if you expect to succeed with software product development.

The changes underway with groups have some positive and negative attributes. First, as a negative, LinkedIn is imposing a cap of 50 groups that any member can belong to. Changes have already started but effective 9/12/2008 if you haven’t already reduced the number of groups down to 50 LinkedIn will do it for you based on the sequence of when you originally joined various groups. While 50 may sound like a lot to some people, I was in 1,351 groups and deciding which groups to keep has been difficult, especially since I initiated and sponsored over 10 groups myself.

On the positive side groups will now have the ability within LinkedIn to support discussion groups, blogs. That means for a lot of groups you won’t need a Yahoo Group or something akin to that as a base and although the feature set may be more limited you’ll have tighter integration. Another negative is that LinkedIn could ultimately control your group since they control membership in LinkedIn. Stay tuned for updates as to how this is progressing.

If you haven't experienced what's available in terms of groups from LinkedIn, here's a way to check it out. Groups are free to join and when you perform a LinkedIn search, you can specifically search within specific groups. Support Chicago’s 2016 Olympic bid by clicking the link below and Joining the Chicago 2016 LinkedIn Supporters Group:
http://www.linkedin.com/e/gis/54811

in Technical Blogs

The self licking ice cream cone that is blog awards has dripped on Agile Ajax. We've gotten a nod from Computer Weekly for the IT Blog Awards 08 as one of the best programming and development blogs. Funny thing, it's a list for the UK, and we've got offices in Chicago and New York.

To curry favor with the voters, we'll start blogging about tyre's and setting colour in CSS. What is it they say? Two peoples divided by a common language?

Anyhow, the self licking ice cream cone part. Go and vote for your favorite. Unfortunately, since we didn't make the short list, you can't stuff the ballot box for us.

One of the major barriers to entry for companies offering services around processing healthcare data has been access to data. Who has the data? Typically the insurance companies. At least they have it in the kind of quantities that makes doing serious data analysis worthwhile. Managed care organizations are in second place, but from there you get to piddling amounts quickly. As you move from the heavily consolidated payer end of the industry to the heavily fragmented provider end, the comprehensive data view of the patient is balkanized to the point of uselessness.

This data problem even effects the valuation of companies. I've seen healthcare analytics companies that provide services to hospitals and clinics valued at less than $10 million, while another company that provides the exact same services to insurance firms is valued at ten times that price. Here, as in all things, follow the money.

There have been public/private efforts to consolidate healthcare data in a central store, such as Regional Health Information Organizations (RHIOs). The architects of the RHIOs realized that doing a national information organization would be too unwieldy and smack a little bit too much of Big Brother, but the regional ones have been bad enough, turning into debating societies between vendors, technocrats, and politicians. This has lead many regional health organizations and hospital networks to start their own pseudo-RHIOs. Still, service vendors would have to strike deals with these local entities to get access to data.

Google Health seeks to level the playing field by providing a data repository for personal health data. Individuals would access a Google Health aware service by granting it access to their data. Provided that enough individuals join and enough provider organizations make it easy to import your data, the battlefield now moves from getting data to getting customers. Bring your data, we'll tell you if your doctor is any good or if that surgery is really necessary. We'll help you find the best Medicare prescription plan based on your actual health data and identify generic alternatives instead of the pricey medication that some former-college-cheerleader-turned-pharma-salesperson pitched your doctor.

Some other nice things about Google Health is that it has support for SNOMED. SNOMED is a newer form of encoding clinical data than what is typically used in the US today. There's a whole host of reasons to prefer SNOMED over our current systems (yes, more than one) of encoding today. One example would be that most clinical data that gets collected today is all about getting paid by the insurance companies. What do providers get paid for? Procedures, not diagnoses. Very often in clinical claims data you will run across individuals who have been diagnoses with something like asthma, just so the provider can be paid for treating them. There's no concept like "I am working this individual up on suspicion that they have asthma, but he may not actually have asthma." So the clinical record is littered with expedient diagnoses made just for purposes of getting paid. You can imaging the havoc this plays with doing meaningful data analysis. Anyhow, SNOMED has a richer set of codes that would enable providers to express these sorts of concepts.

Of course Google isn't alone in trying to crack the healthcare data puzzle -- Microsoft is pushing its HealthVault and WebMD and various health insurers with their own PHR (Personal Health Record) walled gardens may yet open them up to other service providers. Regardless, I think the next 5 years promise to be exciting for those of us that develop healthcare software. Finally, the chance for something besides Ajax and social networking to come out of the Web 2.0 cauldron.

---

Read more about Pathfinder's Healthcare Analytics Practince

Competition is the keen cutting edge of business, always shaving away at costs.

-- Henry Ford

I've been working with Java and Microsoft technologies -- .NET most recently -- in one form or another for quite some time. My company, now headquartered in Chicago with an office in NYC, was actually founded in Seattle by a group of four developers that had met around developing an Exchange-based bulk email system to replace the sendmail-based ones that Microsoft was using at the time. In that span, despite all of the food fights about total cost of ownership (TCO), etc., I haven't seen any evidence that Linux, Windows, Mac, Java, .NET, etc., puts you at a significant business advantage one way or the other. Until now.

The reason? Server-on-demand providers like Amazon's EC2, Joyent,
and others have reduced the capital necessary to launch scalable,
server intensive businesses. Google has just launched a similar
on-demand service, and companies like RightScale and CohesiveFT are building mature businesses around managing EC2 configurations.

Facebook applications are just the most extreme example of business initiatives
that can be scaled on demand from $70/month on one EC2 server to
$10,000/month on many dozens of servers running web, application and
database server clusters and farms. Compare that with the old school of
investing in a large data center with a significant fraction of the
hardware and bandwidth that you might need if your business is a
success. What used to cost $100k in capital can now be done with just a
few hundreds of dollars.

And it's all possible as long as you are using a unix variant -- Linux for the most part -- to power your apps. So there is a whole class of companies out there using Linux that can out compete their Windows-using rivals -- again, the capital they need to launch is much smaller because of cloud computing. That means Linux will win among the class of young entrepreneurial businesses that are so vital to the US economy.

Before the flames start raining down from the sky, please understand that I'm not bashing Windows and
.NET. This isn't about the inherent advantage of one operating system or platform over another. Oracle, IBM and other providers of enterprise software will also feel the pinch as mysql and postgresql outcompete Oracle and DB2 among startups.

There are a whole class of companies that cannot or will not use on-demand computing for security and other reasons. Health care, financial services and other industries that have high security requirements will likely maintain their own data centers for the foreseeable future. But that leaves the majority
of US and World businesses open to the benefits of on-demand servers. (Truly huge comsumers of cpu and bandwidth will be able to get better deals by maintaining their own data centers, but at that point they
will have "made it.")

Microsoft need to follow through on their promise to enter the world of cloud computing (and not this kind of BS "cloud computing"), or all the good they have done with .NET 3.5 will be wiped out. Their Live Mesh doesn't seem to be the answer (more about the desktop and collaboration that cloud computing). Steve Balmer and company have a lot of thinking to do if they're going to square Microsoft's price per CPU model with the price-per-hour model of on-demand computing.