My Work Philosophy

Thursday, 5th March 2009 in Strategy by Simon | No comments

Okay, so many of the points below aren’t purely my philosophy, but ideas and principles I have picked up along the way throughout my [development] career. Some relate to the UNIX philosophy, or even the Zen of Python, but wherever they’re from, they can be applied to many other domains.

  • Don’t reinvent the wheel unless you really have to. Borrow code and ideas from elsewhere whenever it makes sense. The web community it great at sharing, just look at the various JavaScript libraries, the huge quantities of APIs or indeed the major players’ developer areas: Google Code, Yahoo! Developer Network, Mozilla Developer Center, Adobe Developer Connection and Dev Opera to name five I regularly refer to.
  • Things should be as simple as possible, but no simpler (Einstein). This idea is really born out of and emphasised by 37Signals’ Getting Real book. Commonly, 90% of people using an application only use 10% of it’s functionality. The key therefore is to find what people use most often and only build that functionality. If there is a requirement to add more, then sobeit. This can also apply to the code-level, the essence here being a balance between over- and under-engineering something.
  • Do one thing well (The UNIX philosophy). It is better to do one thing well, than several second-rate. This could be at the code level — think encapsulation, coupling and cohesion — or indeed at the application level — you’re never going to beat Microsoft Word, but Google and Zoho have developed compelling alternatives, but with far less features.
  • Don’t fret too much about performance — understand how to write efficient code and plan to optimise later if or when needed.
  • Don’t try for perfection because good enough is often just that. This of course is a matter for conjecture. If I were working on a personal project, I may be more stringent on perfection than say, for a client’s application. This doesn’t mean to say the client’s application would be any worse, but rather it is a question of dotting-the-is and crossing-the-ts. It also depends on your perspective and what gains can be made by aiming for perfection.
  • (Hence) it’s okay to cut corners sometimes, only if you can do it right later. I rarely adhere to this! It makes sense to do it right the first time, since bodge-jobs often come back to haunt you and result in double the effort!
  • Don’t fight it; go with the flow. This is somewhat clichéd, but the essence behind this is try to avoid getting stressed out. This isn’t always easy to achieve, but taking a step back from a situation and avoiding politics is important.

I often strive for perfection, which isn’t an entirely clever pursuit since it is almost impossible to achieve. However, in a realm of imperfection, the principles above have helped me to achieve a modicum of decent code throughout the years. They may also resonate and provide inspiration for you.

Let’s not Dilly-Dally: ColdFusion has its Merits

Friday, 9th January 2009 in Development by Simon | 11 comments

ColdFusion is 13 years old. That make makes it the daddy of the web world! It does not make it any less hip or useful than the relatively new kids on the block.

Take this scenario. A company I once worked for had what can be described as a business directory built upon a licensed, yet bastardised, version of a popular ColdFusion-based CMS. It didn’t work that well! The decision was made to redevelop the application in Java. It took two years to reach the same level of functionality! What happened next? Ruby-on-Rails is what! The rest is history and beyond the topic of this post.

So, in effect, the application almost went full-circle in its development paradigm — both ColdFusion and Ruby-on-Rails can be considered Rapid Application Development environments, Java, certainly not. Why did the decision makers not stick with ColdFusion and put time aside to actually build it properly in the first place? To put it simply, they lost faith in ColdFusion; it was largely mis-understood.

The weakness of every programming language does not lie with the language itself per se — albeit it can have an important influencing factor — but rather with the ability, or indeed inability, of the developer to leverage the language in the most efficient and optimal way.

ColdFusion, like every other programming language has had and I’m sure still does have its fair share of poor developers; those people simply working with it as a means-to-an-end, rather than those passionate about the language, those people programming without understanding the fundamentals of programming or the implications of their poorly written code. This is apparent from .NET to Java, ColdFusion to Ruby, JavaScript to ActionScript.

Let’s not dilly-dally, bicker or insult one another about which is best, which one is dying and which one is not worth the computer it is compiled on. What is important is to understand the merits of each language and decide which one best suits the application, not only in technical terms, but also in terms of time-to-market, cost of development, availability of a skilled workforce etc.

ColdFusion, whether rightly or wrongly in some people’s opinion, can sit proudly amongst its peers and provide a truly compelling alternative.

Here’s how (in no particular order):

  1. Low Total Cost of Ownership – frequently, ColdFusion is described as expensive, it simply isn’t especially if you consider the natively supported functions. But to put it bluntly, if your company cannot afford the cost of ColdFusion standard, or indeed ColdFusion hosting, you have bigger things to worry about regarding the profitability of the company; you won’t be able to afford much of anything! The problem becomes not the product. ColdFusion applications are quicker to develop and developers are vastly cheaper to employ than their peers in Java or Ruby, just look at ITJobsWatch for examples.
  2. Rapid Application Development – ColdFusion vastly simplifies tasks. What would take other languages numerous lines of code to produce is efficiently encapsulated either in a tag or function or as a setting in the administrator. This is a simplistic yet indicative example: where else can you connected to a database simply with one line of code or indeed simply by name? ColdFusion changed the idea of specifying development time in terms of months and years to weeks and months or small features a matter of hours and days. Simplicity is not the mother or all evil. To be pragmatic, simplification reduces costs.
  3. Rich Internet Applications – ColdFusion may or may not have pioneered the RIA paradigm, but it has played a significant supporting role to Flash and now Flex. ColdFusion natively supports Flash remoting, providing the all important data access tier.
  4. Platform Maturity – ColdFusion 8 is built upon the latest version of Java (1.6). Along with internal improvements to the ColdFusion application, this has afforded ColdFusion unprecedented speed improvements and stability.
  5. Language Maturity – with each major release of ColdFusion comes many language enhancements added to the core. This means that previous addons, for example image manipulation, which came at a premium are now standard. Adobe and other companies that produce CFML engines are now participating in a CFML advisory committee, which aims to set standards for the core language. This is not only a sign of maturity but a letter of intent by the industry that will mean your application will work on any engine, assuming no proprietary functionality is used.
  6. The Ultimate Middleware – ColdFusion sits comfortably between any backend and front end system. Be it interfacing with a host of databases, Java, .NET, COM, Corba or connecting to classic HTML or rich Flash, Flex and AJAX frontends with little or no configuration.
  7. Feature Rich – what other web technology natively supports PDF generation, charting, enterprise-level search, AJAX, image manipulation, Atom and RSS creation, Zip and JAR file manipulation, a server monitor, Flex integration, encryption libraries, all important database connectors, webservice creation, XML manipulation, inbuilt reporting application (similar to Crystal Reports), email, FTP to name but a few? I hazard a guess at none, unless you’re happy to pay a premium.
  8. Platform Independent – since ColdFusion 6, when Macromedia redeveloped the entire application in Java, ColdFusion has been platform independent. You can install it on practically any machine.
  9. OpenSource Alternatives – BlueDragon and Railo are both significant alternatives to Adobe ColdFusion and both have opensource alternatives, the latter of the two having recently joined the JBoss community. Adobe are also considering providing a free edition to academic institutions.
  10. The Future – many commentators have mentioned Hibernate as a significant addition to the next release of ColdFusion, version 9. But having seen the prerelease notes, that is not all that will be added. Alas I’m under NDA, but rest assured, there is going to be a significant intake of breath when developers get hold of the next release. ColdFusion 8 was firmly geared towards middle management with fuzzy additions, ColdFusion 9 is set to re-address the balance with compelling language and functionality enhancements.

ColdFusion evangelism needs to step up a gear! Adobe certainly doesn’t afford much marketing budget to the product, prefering The Community do the hard work. It is not always easy convincing the decision makers that ColdFusion is a good product of choice, without Adobe’s unnerving support, but we have to work hard, break down those barriers, encroach on events outside the comfortable sphere of the ColdFusion world and demonstrate ColdFusion’s match-winning ability.

ColdFusion isn’t dying, it’s simply niche. Every niche has its place.

UPDATE: If you would like to view the ensuing debate regarding ColdFusion prompted by Aral Balkan, feel free to do so. This post should serve as a positive reminder of ColdFusion’s virtues, alongside the need for a balanced and polite debate.

Adobe AIR for JavaScript Developers – O’Reilly Pocket Guide

Friday, 18th April 2008 in Development by Simon | No comments

Adobe AIR for JavaScript DevelopersMike Chambers announced at the onAIR tour London event last week that he would be releasing an electronic version of the Adobe AIR for JavaScript Developers pocket book, by the publishers O’Reilly, under Creative Commons licence terms. Well, good to his word, you can download the pocket reference from the Adobe onAIR website.

This book is the official guide to Adobe AIR, written by members of the AIR team. With Adobe AIR, web developers can use technologies like HTML and JavaScript to build and deploy web applications to the desktop. Packed with examples, this book explains how AIR works and features recipes for performing common runtime tasks. Part of the Adobe Developer Library, this concise pocket guide explains:

  • What Adobe AIR is, and the problems this runtime aims to solve
  • How to set up your development environment
  • The HTML and JavaScript environments within AIR
  • How to create your first AIR application using HTML and JavaScript
  • Ways to perform an array of common tasks with this runtime

Also included is a guide to AIR packages, classes, and command line tools. Once you understand the basics of building HTML- and JavaScript-based AIR applications, this book makes an ideal reference for tackling specific problems. It offers a quick introduction to a significant new development technology, which lets you combine the reach and ease of the Web with the power of the desktop.

Software Engineering … The Other Way

Thursday, 3rd January 2008 in Development by Simon | 2 comments

Software development is an often complex affair, beset by a multitude of difficulties ranging from talentless developers, feature bloat, stakeholder politics and poor planning.

The following cartoon, by Alex Gorbatchev, is a modern take on an old, yet still relevant, problem; the reasons for software engineering failures.

Software Engineering Explained

Designing systems today is difficult because there is no consensus on what the problems are, let alone how to resolve them.

Software engineering is often used to solve complex problems, problems where it’s impossible to visualise all the difficulties you’ll run into without actually building the software. This has led to what is known as Wicked Problems. In other words, writing code doesn’t kill projects, too much planning, too much functionality and too many stakeholders do!

Wicked problems arise when an organization must deal with something new, with change, and when multiple stakeholders have different ideas about how the change should take place.

Every wicked problem can be considered a symptom of another problem.

The article goes on to recommend the iterative development process, first proposed by Takeuchi and Nonaka in “The New New Product Development Game” called Scrum. An iterative, as opposed to a Waterfall, process is clearly a step in the right direction. The customer really needed a simple tyre swing but couldn’t articulate that in a meaningful way. Since we’re software developers, not Zen Masters, an answer is to quickly develop a solution in for the customer and keep evolving that solution based on real usage. That way, we can get from the plank to the tyre swing without the need for the roller-coaster ride of complication.

Drive Business Change with Web 2.0

Tuesday, 21st November 2006 in Social Media, Strategy by Simon | No comments

Web 2.0 will alter the way that businesses develop and apply innovative ideas.

During the 1990s business leaders and venture capitalists grappled with how they would make money from the web. This was tipified by the two VCs, Kleiner Perkins and Sequoia Capital, investing $25 million in Google in the late 1990s; they new the search engine created by Sergey Brin and Larry Page was a winning formula, even though the pair had not yet monetised search. Bricks and mortar compaines were deemed “old hat” as the dotcom bubble was expanding. Companies such as eBay, Amazon and Yahoo! were at the forefront of every investors’ chequebook. Every company needed a 21st Century “Blue Sky” web strategy; every company needed to do e-commerce. However, the bubble burst and everyone was brought down with a bang. Boo.com is a classic example of the fallout from the over speculation.

Today, the reality has shifted from solely bricks and mortar or dotcom, to a balance between the real world and cyberspace, of traditional business operations complemented by the unversality provided by web-based technologies. The web has given businesses a greater understanding of their customers. With Web 2.0 a new type of web is emerging, further enhancing the understanding of a user or customer through the creation of online communities, where information is shared and new ideas evolve.

There are numerous examples of web communities from the early FriendsReunited to MySpace and the more specific Islandoo for the Channel4 TV progamme Shipwrecked. Web 2.0 is all about collaborative networks tipified by Flickr, del.icio.us, Wikipedia and YouTube. However, Web 2.0 has primarily been used in the consumer arena, as identified by the examples, but the use of such technologies has far reaching implications based on understanding how people interact with the technologies and behave online. Linking people across countries, time-zones and company boundaries will enable people to work together without hierarchical boundaries, bringing people together as one team to collate the best input. This is emphasised with the concept of a wiki whereby any end-user can make changes to the shared resource without the need for specialist software and expensive training. This makes sharing knowledge extremely easy.

Other areas of Web 2.0 is the technology identified by the term “folksonomy”. Simply, a folksonomy is defined on Wikipedia as:

… an Internet-based information retrieval methodology consisting of collaboratively generated, open-ended labels that categorize content such as Web pages, online photographs, and Web links. A folksonomy is most notably contrasted from a taxonomy in that the authors of the labeling system are often the main users (and sometimes originators) of the content to which the labels are applied. The labels are commonly known as tags and the labeling process is called tagging.

While it takes time for an expert to create a taxonomy specific to a particular organisation in order to categorise or define data, folksonomies do not require fixed taxonomies. Instead, users define their own descriptions of the data to be described by applying tags to the data, whether it is a bookmark in terms of del.icio.us, an image on Flickr, a video on YouTube or a document in a company repository. Over time, these tags can be amended by other users resulting in a definition that is more specific. This enables users to find information with relative ease, without having to type the exact keyword.

Web 2.0 will bring a whole host of issues into the business arena. While there are clear benefits from establishing communities and social networks, people with different views, be it political or religious, can drive the agenda. Further complications arise through the necessity to audit changes to the data and ensuring the data is indeed accurate (Wikipedia has had cases where people have maliciously altered data to either enhance their own profile or devalue the significance of historical events).

ColdFusion Development Tools

Thursday, 17th November 2005 in Development by Simon | No comments

  • ColdFusion Studio, the original ColdFusion IDE, based on Allaire’s HomeSite and subsequently replaced by Dreamweaver and Homesite+ after the Macromedia takeover.
  • Macromedia Homesite
  • Macromedia Dreamweaver, WYSIWYG & code editor.
  • CFEclipse, a ColdFusion plugin for the Eclipse IDE.