Building a proof of concept? Try Twitter

The journey from idea to mature software typically follows three very high level stages:

Proof of Concept > Evolve > Mature and maintain

Each stage will involve the usual development concerns (analysis, specification, design, implementation, integration, stage & tests) with all the corresponding artefacts (stories, acceptance criteria, points, etc.) involving sprints, scrums and whatever other rituals in your culture. The concerns at each stage can also be broken down further. For example, design will typically involve content, logical and presentational aspects. Presentational aspects will require thinking about user experience and be part of a holistic information architecture.

Some idea thrives on a certain component, such as user experience or underlying content. Some thrives on feature or functionalities. Many ideas in one way or another require some form of social acceptance, and this is often key to social or commercial success of the software. Social acceptance is in many ways the golden goal. Many projects invests heavily, at the proof of concept stage, to better understand the potential of social acceptance by creating an alpha or beta version of a software. While the creation of an alpha or beta version complete with its own front-end clients and API can definitely strengthen the case for success at the proof of concept stage, there can perhaps be another way to focus more on social acceptance of the idea socially. Twitter presents itself as a low cost platform for such a use case. It has most of the components required for a bootstrapped proof of concept software:

• Storage: Twitter stores tweets



• Input/Output: Input via 'What's happening?', API. Output to public/follower's Timelines



• Events: Tweets, mentions, re-tweets



• Messaging: Again, via tweets, DM (direct messaging) between users

Processing units are external to Twitter though. The processing units are the users. Users can be biological or software bots. Software bots are easily scripted using available Twitter libraries. Theoretically, we can even run both an asynchronous message queue (via the following-follower mechanism) or a distributed worker farm (via DM-ing) on Twitter.

So, here we have a medium to build a proof of concept, by building a Twitter bot tapping on Twitter's API. The fun part stems from the social aspects. Our software bots can interact with biological users voluntarily or automatically. From these interactions, we learn more about the idea and gather proofs that the gist of the concept works or not.

Remember "The Network is the Computer"? Remember perhaps the Unix philosophy?

• Write programs that do one thing and do it well.


• Write programs to work together.


• Write programs to handle text streams, because that is a universal interface.

From a practical perspective, these mantras are not just useful in constructing good software, it helps in worldly efficiencies as well. Let's say I have an idea to start a food recommendation service. What I could do at the beginning is:

• Write the API


• Database


• PHP/RoR/Python/NameYourLanguage


• Web-server


• Message Queue


• Email


• Cron


• NoSQL


• Caching


• Design RESTful endpoints


• etc.


• Write the Web front-end


• PHP/RoR/Python/NameYourLanguage


• Front-end design


• CSS


• Cross-browser


• jQuery


• etc.


• Write the mobile app (Android or iPhone)


• Objective C / Java


• AppStore submission


• Mobile design


• iOS / Android quirks


• etc.

Or I can write a Twitter bot:

• Write the Twitter bot


• The food/restaurant recommendation algorithm


• The food/restaurant database (stored as Twitter lists?)


• How biological users use and react (analyse via Timeline?)

By going the route of the Twitter bot, I write no front-end (users interact with the bot via Twitter web, TweetDeck or whatever client they use which suits them), I don't worry about storage as most interactions are stored as tweets, I don't worrry about scalability. I focus on writing my recommendation bot that does recommendation well.

You may argue that the user experience is different and that may play a big part in the success of the idea. Probably and of course, the API, web front-end and mobile-app are all eventual concerns. But only IF your idea does well. And in most cases, ideas has to evolve, be tweaked and even changed before it comes to a point where its polished and scales. Would an early stage software project exploring and validating ideas need to expand the whole arsenal of technologies for that? Would it be efficient for a an early stage project to do so?

I will like to put forth this idea that Twitter bots/applications tapping on the API can be a useful tool for such early stage proof of concept and exploration. The artifacts created in the form of these software that lives cronned by the minute to Twitter could even live on as a great service to biological entities on Twitter even if the adventure is validated. It could even evolve into the core of the eventual sofware entity. It could serve as the missing piece between thinking and analysing an idea versus implementing a more involved software artifact of the idea. I am using one myself in the form of a Twitter bot by the name of @watweat, which does: food recommendations! I figure a couple of hours to create a proof of concept to renounce/validate the viability of an idea is pretty good ROI.