Koichi Hirano's Weblog

I have recently had the opportunity to interview Satoshi Nakajima and Yuuichiro Masui, developers of PhotoShare, an iPhone App from a startup called BigCanvas Inc. PhotoShare is a photo-lifelogging app—a photo version of twitter for iPhone, so to speak. Users can upload photos captured with the iPhone camera and share them with people publicly, with friends, or with family (e.g. sharing a baby's photos with the grandparents).

As of now (only 19 days since the release), more than 2000 photos are uploaded everyday at PhotoShare. Most of them come from iPhones all over the world. This is an amazing accomplishment to achieve from scratch for an unknown startup. I flew to Seattle to interview the developers in person.

What's Happening at PhotoShare?

Koichi Hirano (KH): I was surprised to see more than 2000 photos uploaded within two or three days of the launch. What is going on at PhotoShare now? Is it getting more popular?

Satoshi Nakajima (SN): Yes, we now have more than two thousand photos being uploaded every day. We have observed that many users are starting to use PhotoShare even more frequently. They now seem to be starting to use PhotoShare as a lifelogging tool. An example. I have a friend whom I met through PhotoShare in Japan. He uploads photos frequently, like what he had for lunch, where he was and so on. So I know he has had Ramen noodles for lunch for the past three days. He is sharing his life with me through PhotoShare. He looks like he is enjoying photo-lifelogging, and I am enjoying looking at his photo-lifelog. Our users are from all over the world including U.S., Japan, Hong Kong, U.K., Amsterdam, Canada and so on. That's what's been happening recently.

PhotoShare also has a very high participation ratio, too. A participation ratio is the ratio of the number of users who are actively generating content to the number of total users (active users + read-only users). At Web 2.0 Expo 2007, I saw a presentation which said YouTube's participation ratio was 0.4% or so. At PhotoShare the ratio is about 70%. I mean about 70% of users are uploading several photos every day.

KH: That's pretty high.

A Healthy User Community

SN: Additionally, our user community is very healthy. Users are protected from inappropriate photos now. At the beginning, some users uploaded pornography, which was against Apple's policy. We had a feature which allows any user to report inappropriate photos to us. When a user reported such a photo, we would review it and delete it when necessary. As it turned out that this manual process was too slow so we changed the feature. Now if any user alerts us about a photo, our app will keep the photo hidden until we review it.

Now, if a person uploads a pornographic or inappropriate photo, other users will flag the photo using this feature within several minutes. Recently, a user in the U.S. uploaded a photo of a hand-written piece of paper which said something like "Stop using stupid Asian letters!" which we thought was offensive to the diversity of the world. That photo got reported and hidden via user alerts, not from Asian users, but from other U.S. users. We are very impressed with healthiness of our community.

Why PhotoShare has Become so Popular

KH: It seems to me that the kind of success that you achieved it is next to impossible to have within two weeks of release on the web nowadays. You have huge competitors like Flickr, and many other giants in the Photo arena. It would seem like there is no room for late comers. What was your secret? Did you hire a PR firm to promote PhotoShare? Did you pay sexy users from MySpace to upload their photos at the beginning as promotion?

SN: We did hire a PR firm to promote PhotoShare inside the media, but this has not become effective yet. It may take time. And we didn't pay anybody to use PhotoShare. Therefore, this success has been purely due to the fact that we were able to submit the application to Apple by the deadline date, which was I think July 7th or 8th.

Yuuichiro Masui (YM): Our application was listed as the second app in the Social Networking category at the App Store (Apple's application store for iPhone users) at the very beginning, simply because our application name there was "Big Canvas PhotoShare" which starts with "B". So it was well-exposed to public at that time.

KH: It was reported that during the first 72 hours of the App Store launch, 10 million applications were downloaded.

YM: Yes. That way, we were able to reach people who were playing with various iPhone Apps.

SN: The reason we hired the PR firm was that we wanted to be mentioned at TechCrunch. But at the moment, not achieved it yet.

KH: So you are telling me that you not only have had no mention at TechCrunch, but you didn't even cheat by paying users to boost your apparent popularity? Basically your success is solely based on meeting the submission deadline at Apple? Your user community has grown organically, and PhotoShare's vision has been sufficient. I suppose I should ask you how you come up with this app?

Why Did You Start Your Company?

SN: To tell the truth, we originally started this project in order to obtain Yuuichiro's U.S. investor's visa. I met him in Tokyo in October 2007 for the first time. I could tell that he was a good geek and he said he wanted to live in the U.S. Within 30 minutes, I proposed that we should start up a company in the U.S. so that he could apply for a U.S. class E visa. We did not have any ideas for PhotoShare then. In March 2008, for the visa application purposes, we needed to write a business plan for the company. We had a discussion by chat. I brought several ideas, and the idea of a photo sharing service interested Yuuichiro. At that time, I was cracking the iPhone SDK (NB Apple released the iPhone SDK in the early of March 2008) and was really into it. So we decided to go for a photo sharing service as an iPhone App.

YM: I wanted to have a photo service with which I can share my daily photos with people like my grand parents, who are not internet-savvy. So in that sense, I liked the plan. However, I was also very skeptical about the idea of photo sharing. It was obvious that there were many photo sharing/storage players like Flickr and I was not sure how we could really differentiate our prospective service.

PhotoShare Underdoing Competition

KH: PhotoShare users seem to be developing a culture that's quite different from Flickr's. Flickr users spend a lot of time to making their photos beautiful and even artistic, whereas PhotoShare users are just uploading quick snapshots casually and frequently. The vision of PhotoShare, or "Photo-lifelogging", seems to be understood and well-received by many users, and this vision itself has successfully differentiated PhotoShare from other players. So I want to know how you come up with the vision? Did you have that in mind from the very beginning?

SN: Well, I wish I could say I'd had that vision clearly from the beginning, but I didn't (laugh). However, we reached the progression to this vision very naturally because there were already several popular photo sharing/storage services on the internet. Due to this fact, we knew we had to fully leverage the fact that we had nothing. You know Flickr already had tons of accounts, which we didn't have at all. We were really a new startup. Thus the logical conclusion was that we should aim for non-Flickr users. I mean people who don't even know what Flickr is. We figured that this market would be huge. Another key point was to make the app so that new users can register very easily, meaning the registration process should be throughly minimized. If Flickr develops an iPhone app, it is obvious that users will sync their account information with the iPhone app. So we knew that our app needed to excel in this regard to compete with existing Flickr users' experiences on iPhones. And we started with the very simple idea of sharing photos of people's daily life with friends or families. So even though we concretized our vision of "Photo-lifelogging" later, the idea was already there when we started planning the app. Once we decided on our vision, we did not look at the features of any other existing players. We felt that would have caused us to start to adding this feature and that feature and end up with an unusable app. We just focused on our vision.

KH: If you are targeting non-webby people, you really don't need to be mentioned by TechCrunch. TechCrunch is really a popular media among VCs, startups, web designers, programmers and heavy users of web, but none of them are your target demographic. So even if TechCrunch had posted about PhotoShare, there might have been no positive impact to your target prospective users. Perhaps it was lucky for you that you didn't make it into a TechCrunch post at the beginning.

YM/SN: (Laugh)

SN: I could describe our service to potential investors very nicely now. We have seen the advent of the Text communication age that followed the onset of voice communication. Now this age will lead to photo communication..... or something like that. But we are not actually interested in investors.

We Were Supposed to Win Apple iPhone App Award

KH: I read Satoshi's blog post in which he declared you were determined to win the Apple iPhone App Award.

SN: We were there at WWDC to receive the award. It turned out that many winners are famous players on the web such as Twitterrific, AOL and OmniFocus, but not new startups like us.

KH: The best iPhone Show Case in the social networking category was Twitterrific. Although I think Twitterrrific is a great app, I wrote about this in my post arguing that PhotoShare should have won the award because you guys show the fullest potential of Apple's platform, without relying on user assets on the web.

YM: Two or three people from apple seemed to review our app quickly and left. They did not carefully look at PhotoShare. And at that time, there were only three test users who had uploaded photos, Me, Satoshi, and my wife. The contents might not have been particularly exciting at that time.

PhotoShare Running on the Cloud

KH: So you were ready for the award? Also, in your blog post, you said that you were trying to handle 300 thousand users. How did you design your backend?

YM: We are running all of our servers on Amazon EC2 and storing uploaded photos at Amazon S3. The backend is built on Ruby on Rails. There are two big EC2 instances for database servers, one instance for load balancing with PerlBal, one for caching contents, two for Apache, and some for mongrel.

KH: Somewhere, you said your performance criteria was handling 300 thousand users. So, that is roughly one photo upload per second? That's about 46000 photos daily.

YM: Yes, we can handle that now. And we can scale out very easily by adding mongrel instances and changing the load balancer configuration a bit.

PhotoShare, Only 2 Developers and Not Hiring

Photo: Satoshi Nakajima (Left), Yuuichiro Masui (Right)

KH: Now tell me about your team. How many people do you have there? When did you start developing it?

YM: Satoshi does the iPhone side development, and I do the backend and keep the servers on the cloud running. And we also have Adam who oversees legal and operational things. In total, 2 geeks and 1 suit.

We started to develop this app during the second week of April, 2008. The submission deadline date at App Store was July 7th. We had only three months. In my professional experience, I used to spend 2-3 months to set up a robust, reliable infrastructure. Satoshi told me to prepare an infrastructure which could handle 300 thousand users. That was to assure the reliability of the project. But we also had to complete user interface design, application development, and building the infrastructure all in the three months. I shouted "No, I don't have enough time!"

SN: Indeed. If any of us had caught a cold during the three months, we could have never finished that by the deadline date.

YM: I worked from 10am to 3am, and Satoshi worked from 3am and went to bed at around 11pm.

SN: It was only possible because this project was ours and there were only two passionate developers. We are not VC-backed. If we felt any part of project was owned by somebody else, we would not have been that motivated. If we had one million dollars invested by VCs, we would probably not be successful, either. With one million, VCs would tell us set goals, spend a lot of money, hire people, and achieve the goals. We would need to give fancy presentations to VCs regularly which would consume our time, and would need to spend time to hiring and managing people. Under those circumstances, we would not have finished the development within those three months. We are two motivated developers, and that had turned out to be enough and efficient. We are the guys who brought this miracle to pass. We are not aiming to be VC-backed. It's just because we would like to be successful.

KH: I believe the 37signals people would love to hear about your method of success, although the TechCrunch people would not be very happy about it.

SN+YM: The key was not to hire people.

Next Small Things, But Not Next Big Thing

KH: What is the next thing for you at PhotoShare?

SN: First of all, we would like to build our community and provide continuous tweaks to satisfy our users. Then, we would like to introduce some priced plugins for PhotoShare, such as a photo editor or annotator for further enjoyment. The price of these tools should be equivalent to a cup of coffee. If the number of users is large enough and 5% of users purchase the plugins, we could be pretty profitable as we are only three people. That is our business model. We would like to run our company like a good local Italian restaurant. We will spend a week or so to develop a plugin, then release it to see how it goes. We would like to do this kind of things with various ideas. An italian restaurant would not invest a year in preparing new a la carte menu item would it? They just add a new dish after spending about a week experimenting. If it does not do well, they just take it off of the menu. That is it.

KH: When will you introduce the plugins?

SN: It will be after we are confident in the growth of our community. We hope it will be at the beginning of 2009. One idea is for a preset device which a user can send to less tech-savvy users like grandparents to share their uploaded photos in a television. We have plenty of other ideas along these lines.

Apple vs Microsoft

KH: Do you have any comment on Apple? iTunes, iPhone, or iPhone App Store?

SN: Just that it's incredible. I want to say "Hey, what were you doing Microsoft?" Apple announced the iPhone SDK at the beginning of this year 2008, and released it at the beginning of March 2008. It has been only seven months since the announcement. Now, there are more developers for it than those around Windows Mobile or Symbian OS. Developers are moving from those platforms to the iPhone because they understand they can do much more interesting things on iPhones. I should point out that iPhone excels in terms of hardware and its operating system. In that sense, Microsoft is three years behind iPhone.

KH: Satoshi, you could go back to Microsoft and rewrite the Windows Mobile OS from scratch (Note: Satoshi Nakajima lead a Windows 95 developing team at Microsoft).

SN: I would hate to do that. I could do that technically speaking, but I don't have any real motivation because Microsoft is not my company. The very key to us is building a small team and growing it organically. In that sense, our future success, if any, will be simply because our company was founded for Yuuichiro's visa application. You can not start up a company with VC money for a visa of a person.

KH: Satoshi and Yuuichiro, thank you so much for this stimulating discussion.

On July 11th, as I wrote in a previous post, I came home from the cellular phone store without an iPhone. It was totally sold out. As I was very interested in what's going on around the iPhone 3G (what kind of people are using it etc.), I checked out an iPhone app called PhotoShare. It is a social photo sharing service available on the iPhone and the web, developed by one of my friends Yuichiro Masui and his colleague Satoshi Nakajima. I visited the web version of [PhotoShare] (http://bcphotoshare.com) and there were already almost two thousand photos already uploaded from iPhones. This number was clear evidence that PhotoShare was rapidly getting popular. To be honest, I found this very surprising because on the web nowadays, this type of Web 2.0 service does not typically get this much traction after a launch in such a short time (I mean, within a day). There are too many similar Web 2.0-ish services out there and the web is very competitive space. I wondered, "What is really going on?" To figure it out I spent some time to exploring photos uploaded by numerous users everyday for a week or so. Some of them are from the so called "MySpace Generation" sexy girls. But most of them are just daily life photos, most of which look uploaded directly from iPhone's built-in camera. I recognized that people were uploading not only in the U.S. and Japan, but also from Hong Kong, Europe, and all over the "iPhone" world (N.B. iPhone is now available in more than 20 countries).

I was excited to see all of the photos, and I felt that there is something innovative around PhotoShare. I reasoned the following.

Most users are not webby nerds

Having seen tons of photos, I felt that the majority of users may not necessarily be webby nerds. Thinking about the price of iPhone 3G, complared with iPhone 1G and 2G, iPhone 3G users would probably include more "ordinary" people, as compared with those of iPhone 1G. Most of iPhone 1G users around me were webby nerds with relatively high income. I definitely sensed that difference this via the photos uploaded at PhotoShare. The style and type of shot on PhotoShare was very different from those of Flickr. I found photos at PhotoShare to be more casual and less art-oriented than Flickr. At Flickr many users really care about the quality of photos, cameras, and photographic techniques used. They invest more time per photograph, from setting up their Flickr accounts to choosing appropriate lighting for a photo.

At PhotoShare people with this much attention to detail were few and far between. PhotoShare seems to have succeeded in reaching people which the current photo web services (at least Flickr) have never reached. I must confess, I am a big fan of Flickr, and I don't use PhotoShare as much as I use Flickr. So, I am am in fact not a person in the market that PhotoShare is approaching. For those who have already concluded that PhotoShare is just another version of Flickr, you may want to reconsider your assumptioin.

Users are enjoying taking daily photos of life and some users are uploading many photos as if they are life-logging

This was quite surprising, too. They seem to be enjoying their photo lives like music! Rather than looking at PhotoShare as another version of Flickr, I think of it as another version of Twitter. PhotoShare founder Satoshi Nakajima mentioned this in his blog.

If my memory is correct, there were only several taps on my iPhone to start using PhotoShare, including purchasing (well, it is free though) from the App store. After installing it, only five taps are required to go from the main screen of iPhone to taking a picture, to completing its upload. It is really easy and quick. This is a very important key for lifelogging. I have been a lifelogger for more than a year. A little over a year ago, I developed a lifelogging web app. Photo-logging was an important part of my lifelogging. I would take a picture of a page of a magazine article that I was reading at a cafe so that I could refer to it later on, I took tons of pictures of someone's presentation at a conference while text-lifelogging on my ThinkPad and so on. What I was doing behind the scenes was quite complicated. First, I had a flickr account. I took pictures with a Nokia N95 smart phone, with ShoZu installed. I set up my Flickr account with Shozu of N95. ShoZu hooked Nokia N95's camera software and it automatically upload photos to my Flickr account via Edge or WiFi as I took pictures.

Then I told the lifelogging app about my Flickr account information. The lifelogging app periodically imported photos from Flickr, just like FriendFeed. Finally, I could refer to the photos as a part of my lifelog. I had to set up several apps, and hardware-wise, I had to go back and forth between the smart phone and my PC. Quite complicated right? Do you think you or your family would like to do that by yourself? Probably not. This is probably the biggest reason why there have been few lifeloggers in the world. PhotoShare, equipped with Apple iPhone and distributed through the App Store, has skipped this complicated processes which one would have to get through if they don't use PhotoShare. Several taps on the iPhone achieves the same thing as my whole process outlined above. Basically, what I was doing with a camera phone, software called shozu, the web app, my flickr account, and several settings with them is now all possible with one device iPhone + several taps. More importantly it is all available to millions of iPhone users! In a matter of day, PhotoShare users have surpassed someone like me who has spent a couple of months figuring out how to do all of that a year ago. Now that the world has PhotoShare on iPhone, there will be more and more photo-lifeloggers. This is huge innovation.

iPhone + App Store could be as powerful the Web

Here is a more general lesson I learned from PhotoShare. iPhone + AppStore has the potential to become a powerful infrastructure or as robust an ecosystem as the Web is. By Web here, I mean world wide web accessible through computers browsers.

Web browsers have been innovative in the sense that they made the distribution cost of services and information ignorable. A somewhat similar thing is now also possible on the iPhone App Store, too. Apple has made it. Apple opened the door of "App Store" on the iPhone infrastructure to developers (although it is not completely open). A good developer can create a successful iPhone app to distribute it to some millions iPhone-addicted users on Apple's iPhone App Store. They can develop anything from a useful office application to games to social web or Web2.0-ish things without using relying on existing web apps (I would say it is a social iPhone). PhotoShare is an early example. Although PhotoShare is also available on the web and they are using the same infrastructure as Web apps' (They are running the service using Amazon EC2, S3, and perhaps SQS, and running Ruby on Rails), from the users' perspective, it is not a web thing (they don't care what a hypertext transfer protocol is).

Everything seems happening on peoples' iPhone. Users don't need to have accounts on the web, even they don't have to have any experience using the internet. An example of the opposite of this is Twitterrific, an iPhone client app for Twitter, which actually won Best iPhone Social Networking Application at Apple's event WWDC08. Although I am a fan of Twitterrific and think it is a wonderful application, I don't think that it shows the fullest potential of the ecosystem of iPhone + AppStore because Twitterrific itself is dependent to the popular web service called Twitter. In order to use Twitterriffic, you need to have an account at Twitter.com. Therefore I find that Twitterrific is an excellent application, but not quite innovative. On the other hand, PhotoShare has demonstrated to me how it is possible to launch a social application from scratch without relying on pre-success on web. They achieved attracting thousands of new users within a week or so without having a preexisting web app thanks to Apple's infrastructure. You may say this quick success at PhotoShare is due to their clever viral marketing strategy or hiring an excellent PR firm, but I would say it may not be the case as viral marketing would take time as we see on the web. So I would say it is solely due to the infrastructure (I will confirm about this with them if I have a chance and keep you posted).

I am not 100% happy about iPhone 3G itself, as written by DHH, but the above lessons are enough to make me happy to have an iPhone. I mean, I am excited about the potential of iPhone + App Store. Props to Apple, and of course, to Satoshi Nakajima and Yuichiro Masui, the developers of PhotoShare. I myself am one of the old-school web app developers, still living within the websphere. Am I going to move onto the iPhonesphere? Well, if my wife decided to purchase an iPhone, then perhaps I would. Until then I will continue what I am doing because there are many things to be done in the websphere, and I am still excited about them.

A week so ago, I bought an iPhone 3G at last. When Apple first introduced the first generation iPhone, I was a resident of U.S. As a person who is extremely interested in technology and user experience, I know that I should have bought one of the first generation iPhones, but I didn't. This was because I was about to move to Canada and decided to keep my Nokia N95 for that time. On July 11th, Apple finally introduced iPhone 3G in Canada, and I purchased one of them without hesitation. I currently live in the country side of British Columbia, Canada and as a matter of fact, I have only seen three people using macs in my town. iPods? Well, I haven't seen any people using them at all. Smart phone? Well, I have never seen such a thing in this town. Actually, I was asked what smart phone means by a resident here when I talked about the iPhone.

Based on these experiences, I figured that there would be no line on the iPhone debut day in front of a cellular phone shop. On that day, I had a very busy schedule as I am dad with three children including a two-week old baby. Somehow I managed to find time to go to the shop at 5 PM and told the guy at the shop confidently "I am gonna purchase an iPhone." Surprisingly, he told me that it was totally sold out. I was deeply disappointed. At the same time, I sensed that something revolutionary was happening not only in Canada but also all over the world. In a small town with almost no Macs, iPods, or smart phones, the iPhone 3G was completely sold out. As a matter of fact, according to an automated message from Fido (a carrier which sells the iPhone in Canada) customer service line, iPhone was sold out and people should place their names on the waiting list. Well, that weekend completely changed my perception Apple. Apple is doing far better in Canada than I expected.

Agile Software Development is a style of software development which has been gaining popularity. According to a former colleague, upwards of 10% of corporate software development projects in North America are now conducted this style. Agile Development (hereafter Agile) is to beat the long lasting development style called Water Fall Model (hereafter WF).

Suppose you want to build a dream house. With WF, you hire an architect who designs all the elements of the house . You then move onto the actual building stage (i.e. foundation -> framing -> plumbing/wiring -> walling -> flooring etc). Once you start, you are relatively locked in to the plans. You cannot abruptly change things and decide that a faucet should be installed in a completely different location. Well, you could, but it would be very costly. In this model, the longer things continue to be built, the more unexpectedly things may turn out. And it may not be at all like you imagined. Within the WF model, once a project is in motion, and the "water is flowing," you cannot really go back "upstream" (i.e. the design stage). Instead you must wait for the design to run it's course, and then pay for it. Once the project is in motion you don't have much control.

Agile however addresses the above problems. Agile developers always work with the client step-by-step from the design stage to the flooring installation. Agile developers in fact welcome changes to the plans so they can ultimately build a better home. They always try to show what the actual finished product will be like along the way while working, or in the form of a mock-up made at least to scale. This way the client can confirm what the finished product will look like before it is completed. In a nutshell, Agile's strength is that it permits change derived from mutual conversation with clients throughout the development process.

One very specific and opinionated approach of applying Agile Software Development to create web products efficiently is called Getting Real. Created by Chicago-based company 37signals, Getting Real utilizes Agile Development to build the best web product possible. One of the greatest challenges to developing a successful web product is the fact that you have not met your potential users in person. Also, potential users are quite diverse in their needs and internet savvy. So, you need to explore what would be the best features and interface for millions of different users, which is pretty challenging to do at the beginning of a project. WF doesn't work here because it requires a plan for the product to be set before the construction can begin. But what is really needed is exploration.

Getting Real is quite agile, in the sense that you can create a product step by step, and in each step you observe customer behavior and take into account client feedback. From there you can adjust the product to implement the most recent feedback. If it doesn't work, you can easily go back to the previous step. This rewinding in product development can be confusing to clients at times, but this can be avoided if the changes (or "tweaks" as we call them) are small enough.

37signals' project management product, Basecamp, which I recently started using for coordinating this blogging project with my proof reader Emily (whom I utilize as I am not a native English speaker), was developed with Getting Real. 37signals created Basecamp five years ago. Currently, they have more than 2 million users, and they still continue to change and tweak the product little by little fairly frequently (sometimes weekly, or even daily). It seems that Emily understood how to use Basecamp almost instantaneously. In fact, she did not even ask me any questions about how to use it, and she figured out very quickly what can and cannot be done with the built-in wiki called Writeboard. For several reasons, we are drafting the actual blog posts on Google Docs and doing the rest (like To-Do management and messaging) on Basecamp. The point I am making is not that that there is anything wrong with Writeboard, but that she had to spend only a few minutes exploring Basecamp to grasp what it could and couldn't do. From there it was easy to make a decision—that we should just use Google Docs for editing my blog drafts. It is very easy to understand and therefore made it very quick to reach a decision. We did not have to spend hours figuring out how to do this and that. 37signals has spent five Getting Real years slowly crafting Basecamp in to the outstanding work of art that it is, and as a result it is easy to use, intuitive, and requires no manuals or training.

While Agile development may seem like a logical model, it is actually rare to see it implemented in the real world. I'm sure you have experienced this already. For example, when you call customer service at a company to complain about something, the customer service reps seem like they are listening to your concerns, but they are probably just being polite. If the service reps were working in an agile manner on a web product, they would need to report your complaint to their boss, who would then compile a list of all complaints and once a month report to the VP of Engineering. The VP of Engineering would then prioritize the complaints and pass the highest priority items on to the developers. In this case there are several steps or filters that your complaint must pass through to go from your lips to the ears of the guys actually developing the project. Although the developers try to be agile, there are too many steps in the process. This is what happens in most businesses. Getting Real, however recognizes this problem and recommends doing everything as a very small team. For example a team consisting of myself acting both as a core developer and customer support staff at the same time so as to avoid unnecessary steps in between input and action.

So my company OneAgileTeam remains small, and applies the Getting Real approach wherever applicable. We strive to fully understand both identified and unidentified business needs and fulfill them in the most agile, simple and timely manner possible. And by timely, I mean a few hours to a few weeks at the most. This is the main objective at OneAgileTeam.

A few months ago, I read 37signals' book "Getting Real" and found it fascinating. Its smart methodology helps application developers decide on a vision for their product, while still offering the advantages of Agile Software Development.

Since then I have been applying their techniques to some of my projects and have found them extremely helpful. However, I have encountered some conflict between key points in Getting Real and Manifesto for Agile Software Development.

My question is— is it better to maintain the "Always Working Code" (in the sense of Manifesto for Agile Software Development) without going back to the mock-up stage? Or is it better to halt the "Always Working Code" and go back to the mock-up stage, or even the vision definition stage (which is the origin of mock-ups in Getting Real? I have been at a loss as to how to resolve these conflicting ideas. Getting Real is really smart in the way that in the development process it avoids non-essential codes and features that go beyond a product's vision. For example, it states "Hand-written UI as a mirror of the vision, then move onto its mockups, followed by making the html/css work." That way, when you code, you cannot implement anything which does not reflect the product vision.

However, as I coded, I would often have thoughts such as "Oh, an interface that would make the app work more smoothly is missing here." So, the hand-written UI turned out to be imperfect (as always). In these cases, I generally tended to continue coding, i.e. I would add the missing UI in the coding process. Soon or later, however, I would find that the added UI was not really clean and pretty or it had too many features. Then I would think "Oh no.... I am contaminating the app and it is no longer Getting-Real-ish!"

In the spirit of Agile Development Manifesto's "Always Working Software" strategy, I did the right thing by adding more coding. At the same time, I was not able to stay true to the simplicity of Getting Real's approach because I was over-coding beyond the mock-ups that were supposed to be the mirror of the product's vision. I could have stopped coding the always-working-software by going back to the mock-up process to add the missing UI.

After some experimentation, I discovered that to stop coding and go back to the previous mock-up process to complete the UI worked much better than continuing coding without having the missing UI's mock-up. This not only forced me to spend more time thinking about how to convert the vision into UIs, but it also made me interact with my teammates and potential users while showing the added mock-up. This may not be necessary for die-hard Getting-Real folks, but I found it useful.

If you have felt similarly conflicted on this issue, I would love to hear from you about how you resolved it!