Showing posts with label Development. Show all posts
Showing posts with label Development. Show all posts

Saturday, 12 May 2012

Start Small, Get Huge

The larger a vehicle is, the more fuel it consumes, the more power it needs to move, the more costly it becomes. This is no different to businesses or their products. Thanks to the ever-changing internet, it's possible for a lone man to do more than what entire businesses could twenty years ago. Smart organisations have noticed this, and adapted to exploit it. By changing to a smaller business model that utilises the internet, an organisation can cut costs and for more efficient solutions.


However, becoming lightweight isn't the entire solution. For example, an exploding demographic can easily overwhelm a service, or the competition may change their system to one that's more efficient. Indeed, a business needs to be flexible and scalable to remain competitive. Seth Godin described it best when he said "Get small. Think big." It means to deliver a big product or service, but in a way that minimises cost and resources.

 Some methods that enforce this behaviour include:
  • Outsourcing whenever appropriate - Do calculations off-site or direct specific tasks to specialist services.
  • Using loose coupling - Be able to change methods without changing the end result.
  • Operating fast - Finding and solving problems earlier.
  • Avoid restrictive solutions - Open-ended or remixable solutions enable flexibility.

It's interesting to note that this pattern often overlaps with the Perpetual Beta pattern. A beta may start small, allowing it to grow to fill its audience's tastes. Or a program that continues to evolve may adapt to its competition, or try to appeal to a newly-found niche audience.

There's a lot of roles that can be delegated off-site.
Finding the right methods and services to produce them can save
a fortune, which means success or failure to smaller businesses.
One organisation which "started small, thought big" was Mojang, founded near the end of their first project: Minecraft. Before Mojang was founded, it was just Markus "Notch" Persson, a lone programmer and developer.  Minecraft at this stage was a simple java game embedded in the browser, limited in features and especially buggy in multiplayer.


As Minecraft progressed, so too did its environment. In fact, the website could not keep up with the explosive growth of its user base: repeatedly the servers collapsed from the sheer number of users trying to play the online game. Quickly, Mojang changed its act: Minecraft was altered so people could play the game offline (albeit limited with some features) and found a different plan for its servers so it could cater for the increasing demand.

This quick action allowed Mojang to recover from an unfavourable scenario and averted complete disaster. If the group didn't rely on their host or act quickly, the interest in the game would have dwindled and possibly stopped altogether. As of today, Mojang has since "completed" Minecraft, and has grown both in number and in projects.

References:
OpenText, Low Cost Enterprise Scalability, retrieved 11th May 2012
Seth Godin (), Small is the new big
Mojang Homepage

Saturday, 28 April 2012

Eternal Unfinished

When software was updated, often users would either need to download the fresh new version or download a patch that updated the software itself. This effort relied on users to make sure software was up to date. Inevitably this would lead to compatibility issues with differing versions of software.

For web applications and services, this problem was less of an issue: only the internet application itself would need to be updated. Everyone who utilised the application was using the latest software. However, the service would need to deny access to users whilst updating. But then, there's cases where an application provides its services, but still updates behind the scenes. This is where the Perpetual Beta is most recognised; an online service or application that incrementally improving itself to suit its customers, possibly without denying them the service.


"Perpetual Beta" implies software that isn't quite ever finished, but it would be more accurate to say it's about updating software in small  but often bursts, as opposed to large patches. A website that continually improves itself gives the illusion of being alive as it evolves. There are several advantages to updating often and online over the traditional monthly patch:
  • Gradual Changes ease new features into the system
  • Lower risk of  implementing bugs
  • Increased response to errors and feedback
Being in a state of constant development allows a business to release its product early and take advantage of the aforementioned perks. Unfortunately, the label "beta" is also used as a safeguard to protect the application and service. While users of the software will understand if a feature doesn't work, developers may grow complacent; focusing on features and new functionality whilst ignoring common bugs.



One site which has taken advantage of this pattern is Kongregate, a website dedicated towards flash games. Originally starting with the simple ability to play (and upload) flash games, record user profiles and record the games they play, Kongregate has slowly implemented features such as achievements, forums, contests and a "beta" section (where developers can test their games online and see how they look in the browser). When it began in 2006, updates for the website itself would only be made once every few months, but developers quickly adopted the "Perpetual Beta" format, adding new features and providing a better service for their users.

Kongregate's beginning was slow because there weren't many features or problems to patch, allowing its developers to cover all its primary functionality. When the core essentials were set up, Kongregate reaped the benefits of the developer pattern. The service was able to expand gradually with new features, services, and developers to focus on issues (usually because they were related to said  features).

The flash game website has been fleshed out over the years and continues to look for ways to improve its user experience, but it is never quite "finished."

References:
Steve Matthews, (10 August 2011), Perpetual Beta – The Real 21st Century Library Model?
Wikipedia, Perpetual Beta article, retrieved 28 April 2012
Bill (Praxis101), (17 May 2006), "Perpetual beta" means never having to say you're sorry 
Caroline McCarthy, (18 January 2007), Perspective: Beta--the four-letter word of Web 2.0
Kongregate Website