Some considerations with Open Source

What is Open Source?
Open Source is the practice within software development where access to the source code is granted. This allows a software developer to take the original source code, and modify it for their own specific requirements. Or to extend the original application to perform some function that it did not originally perform. In keeping with the ethos of Open Source, all such changes and modifications must also be placed in the public domain, for other software developers to use.

So the Open Source movement is all about the sharing of ideas and code, by and for other software developers. This is most certainly a good thing. The entire LAMP (Linux, Apache, MySql, PHP) software bundle is based around Open Source, and this is a very widely used development platform.

Another ethos of the Open Source movement is that it should be either free, or incur only minimal costs. Open Source is the antithesis of for-profit, and profiteering would be seen as breaking the spirit of the movement.

Open Source is driven by the ethos of freely sharing your application code and resources amongst others within the software development community.

A work colleague recently asked me why, when selecting a Content Management System for my place of work, I had not considered looking for an Open Source solution.

Given the many benefits of Open Source already described, it might seem to be lacking due diligence not to have considered them in the selection process. While I most certainly have a great deal of time and respect for Open Source, it just doesn't always provide the best solution that perfectly fits every requirement.

While software bundles such as LAMP (see above) are in common use, and have large communities surrounding them that can provide support, assistance, patches and so on, this does not exist for every Open Source product or application.

Risk and accountability
Using LAMP in a commercial environment does not pose any serious risk. It is very well supported within the Open Source community, so while there may be no formal Service Level Agreements in place with a specified supplier, the community is so large, with so many developers and users, that the risk is heavily mitigated.

Open Source applications such as Drupal and Joomla are both excellent examples of Open Source Content Management Systems. They are also both well supported by their respective development communities.

However, a web site forms a substantial investment (and by extension an asset) to any organisation. It will be used to store the organisation's content, documents, images and information. These are things you probably want to ensure are well supported and looked after. There is little comeback if the system fails in some way, so this poses a more serious risk to the organisation. The lack of accountability is their key detractor.

In a commercial setting (public or private sector), web site downtime is critical. So are the threats from the various types of attack that a web site can be subject to including Denial of Service (DoS), spamming and cross-site scripting (XSS) to name a few.

I would be reluctant to place my investment, costing tens of thousands of pounds, in the hands of a community of unaccountable people. This is not to say that the community would not help in my hour of need, but the key point is that they are under absolutely no obligation - financial, moral or otherwise - to do so.

With a non Open Source solution, there is accountability. If I need support, I can pick up the telephone and speak to their support team. If the system fails in some way, there is accountability that entitles me to certain contractual and legal rights, including compensation for any inconvenience that may have been caused.

Conclusion

The amount of risk appetite we have is a very personal thing. For some, the risk I have outlined may be tolerable, especially bearing in mind the tremendous benefits that come with an Open Source solution. For others, the risk is just too great to accept.

Open Source Content Management Systems certainly have their place, and the examples I have given above clearly show just how professional and feature rich they can be. When considering any solution though, you need to have full access to the facts to make an informed decision, and it is worth pointing out that despite the many benefits of Open Source, it is not a magic bullet solution, and has its own drawbacks that must be carefully considered.

Using Landing Pages in a web site

What are Landing Pages?
To be clear from the outset, I am not referring to advertising Landing Pages used in pay-per-click ad campaigns. Instead, I am referring to the lower level Home Page variety of Landing Page. This is a Home Page that sits beneath the main web site Home Page in the overall hierarchy or structure of the web site. To differentiate between a web site's root (or top level) Home Page, and a lower level Home Page, these lower level pages are typically referred to as Landing Pages.

Every web site has a home page, or root page. This is the page that loads when you first navigate to the web site, and without specifying any other criteria, and without navigating there from a search engine result (which may take you to some other lower level page on the site relating to your search criteria).

In the hierarchical structure of a web site, a Landing Page would be positioned beneath the main Home Page. It's purpose is to form a portal for related information, so that all content that is related to a particular subject or item, is grouped together into a suite of pages which collectively are called a Landing Page.

The Landing Page does not in itself necessarily need to contain all the information related to the subject or item, but it should at least provide the portal from where all information that relates to the subject or item can be found. So a Landing Page may be composed of content, links, downloads, images, FAQs and so on. A Landing Page should provide a one-stop shop for its chosen subject or item.

Using Landing Pages is different to the document centric approach, where the web site is built from many related, but separate web pages. Instead, all related information is grouped together into a single Landing Page, so it is obvious that the content is related, and is easier to signpost and navigate.

So just to quickly recap, a web site will have only one Home Page, and one or more Landing Pages.

Why use Landing Pages?
As should be clear from their description, Landing Pages provide a one-stop shop for related information, and therefore allow a user easy navigation and signposting for searching and finding the information they are looking for.

Rather than have related information spread over various parts of the web site, giving no clear signposting that it is in fact related, the user will quickly become confused, and give up trying to find what they were looking for. If your web site is a web shop, and the user has left without making a purchase because they couldn't find what they were looking for, then this should spell disaster!

Designing a web site that uses Landing Pages
The web site design will largely dictate what information gets grouped into the Landing Pages, so it's well worth taking the time and effort to think about how you want your web site's content to be structured, what information should appear on the Landing Pages, and how the Landing Pages are signposted to get the maximum traffic.

I find that mapping the web site structure out first, using a hierarchical or family tree type diagram works well. Each Landing Page should be represented, and all links between them should be clearly displayed.

Using Landing Pages in Local Government web sites
Local government web sites provide a natural fit for a Landing Page approach. As local government web sites use structured taxonomies such as the LGNL (Local Government Navigation List), where the services that they deliver are broken down hierarchically into a service related structure, then clearly each service can have its own Landing Page. For example, you could have Landing Pages for Waste and Recycling, Councillors, Planning and so on. While a document centric approach would still work, a Landing Page based approach is perhaps a better fit.

Summary
So when designing a web site, it's worth considering how you want it to be structured, how you intend to group information together, and how it should be linked for easier signposting and navigation.

Reasons for using Design Patterns

What is a Design Pattern?
Following on from my previous post about Why design is critical to software development, I would like to tackle a slightly more advanced aspect of software design called Design Patterns. As with my previous post, the idea for this post came about during a discussion concerning the merits of software design. The protagonist of the discussion was of the opinion that Design Patterns are too time consuming to be of use within the field of commercial software development. My intention here is to demonstrate why I believe that to be wrong.

I will not go into any details about the mechanics or implementation of any particular Design Pattern. There are many excellent sources for these available elsewhere.

So getting started then, what exactly is a Design Pattern? Here are a couple of definitions for the term:

Extracted from Wikipedia:
"A design pattern in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. "

Extracted from Data & Object Factory:
"Design patterns are recurring solutions to software design problems you find again and again in real-world application development. Patterns are about design and interaction of objects, as well as providing a communication platform concerning elegant, reusable solutions to commonly encountered programming challenges. "

Extracted from Data & Object Factory:
"The Gang of Four (GoF) patterns are generally considered the foundation for all other patterns. They are categorized in three groups: Creational, Structural, and Behavioral."

So a Design Pattern is a general purpose abstraction of a problem, which can be applied to a specific solution. As software developers tend to solve many similar problems, it makes sense that any software solution would incorporate similar elements from other solutions. Why reinvent the wheel?

Well documented and understood
As Design Patterns are well documented and understood by software architects, designers and developers, then their application within a specific solution will likewise be well understood (although given my reasons for writing this post, I should perhaps add the caveat that they will be understood 'only' by experienced software architects, designers and developers).

Design Patterns gives a software developer an array of tried and tested solutions to common problems, thus allowing the developer to save time by not having to think of a new solution from scratch.

To give an analogy of a Design Pattern from the field of civil engineering (which as I stated in my post Why design is critical to software development has close similarities to software engineering), would be to think of a solution for crossing a river. This is a recurring problem for civil engineers, to which there are a couple of well documented and understood solutions. The civil engineers may build a bridge (of which there are many different kinds, but for the purposes of this exercise, let's just refer to them collectively as bridge), or a tunnel.

Close parallels with civil engineering
Why would a civil engineer try to solve this problem from scratch when there are real world solutions that can be referred to? There are close parallels between the civil engineer solving the river problem, and the software engineer solving a software problem:

• The solutions (bridge or tunnel) are both well understood and documented
• The solutions (bridge or tunnel) solve recurring civil engineering problems
• The solutions (bridge or tunnel) are not deterministic or prescriptive, but are abstract and can be tailored to the specific problem (the bridge or tunnel building materials for example can be selected for their alignment to the specific problem)

The argument against Design Patterns that they are not suitable for commercial use due to their taking too long to implement does not hold up. Design Patterns save time by giving the developer tried and tested solutions to many of their problems.

The only issue I have come across with Design Patterns is that they take time to learn. Some of them can be difficult to grasp and comprehend. However, it is worth taking the time to fully understand them, as they will quickly form one of your greatest assets.

Design Patterns reduce complexity, and therefore the solution becomes easier to comprehend.

Design Patterns are tried and tested solutions, the developer does not need to start from scratch, and can hit the ground running with a solution that has been proven to work (as long as the Design Pattern is being used to solve a similar problem; it would be wrong to expect a bridge to solve the problem of crossing an ocean, where a bridge would simply be unsuitable).

Whilst working as a Senior Software Engineer at Pegasus Software, I got my first exposure to Design Patterns in the work place, not just the theory from books. Much of the software framework used to underpin their products was developed using a variety of Design Patterns, including the Class Factory, Decorator, Template Method and Chain of Responsibility. The resultant code was far easier to comprehend, maintain and extend in the future.

Conclusion
Design Patterns, despite their learning curve initially, are a very worth while investment. They will enable you to develop tried and tested solutions to problems, thus saving time and effort during the implementation stage of the software development lifecycle. By using well understood and documented solutions, the final product will have a much higher degree of comprehension. If the solution is easier to comprehend, then by extension, it will also be easier to maintain.

Why design is critical to software development

A good software engineer should always design
I recently had a discussion about the merits of design within the field of software development. My protagonist was of the opinion that design is not something that should be taught in the early stages of becoming a software developer, and that design was largely a matter of common sense anyway. Their opinion of design patterns was that they were too time consuming to be of use in commercial applications. I will address each of these points throughout the course of this discussion.

As a professional software engineer with over a decades worth of commercial experience, and having worked in both good and bad development environments, I know the benefits that come with good design.

I don't intend to describe each of the various design methodologies or design patterns as there are numerous books and articles already available on such subjects. I intend instead to describe why design is a crucial part of the software development life cycle.

Software is an engineering discipline
I always like to use the analogy of a software engineer and civil engineer. Both should employ engineering concepts to achieve their objectives. What this means is that when designing a software application, you should borrow engineering elements from the field of civil engineering.

Here is a definition of software engineering taken from Wikipedia:

"Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software".

When designing a suspension bridge to span a mile wide river, would you really want to just proceed without giving any thought to how you intended to build it. Just turn up one Monday morning, and start bolting steel girders together. The obvious answer is of course not, but this same level of diligence and engineering does not always seem to apply to software development, even it would seem from some of those working within the industry. It would be classed as utterly negligent to build a suspension bridge without having a design in place first.

The earlier you are taught design, the better. Imagine turning up to a course on car building, where the lecturer said "This week I'd like you all to begin building your cars please, and next week I'll show you how to design them". I'm sure you would think there was something wrong with the way the course was being taught.

Before you build something, anything, you design it first.

Software design is not a trivial process
Whilst some elements of software design may be common sense, that does not necessarily imply that it is all common sense by extrapolation. In fact, it is fair to say that the design process can be difficult and demanding. It can take years to develop the experience, knowledge and skills to become expert at it.

Design constraints including extensibility, reusability, tolerance, coupling, cohesion and reliability to name a few, must all be carefully considered. There will also be many trade offs and compromises that must be considered as part of the design. To say that all of this is simply common sense is nonsense.

The design process also manages the complexity that is inherent when building a fully fledged software application. With so many considerations to take into account, the human brain can quickly become overwhelmed with information. This needs to be broken down into manageable chunks that a designer can understand and work with.

Design is the key to communicating your intent
If you don't have a design, how do you and your team know how you are going to build the solution? Design takes time to get right, and can be fraught with problems. I spent several years as an Analyst Programmer, where part of my time would be spent visiting customers to document their requirements. I would then work this into a document explaining as clearly as possible how I had interpreted their requirements. This would also include using use-case diagrams using the formal notation of Unified Modeling Language (UML).

I never got this right the first time. I would send this to the customer for their input, and they would invariably point out the omissions and inaccuracies, for me to then revise the requirements document. After several iterations, you would arrive at a set of requirements that the customer would be happy with (for now, but that's a whole other story).

A similar process can and should be employed in the design process, taking the requirements document, and iteratively shaping this into a working design. The software design should form the key communication tool amongst the software team.

What do you mean you don't have time?
I have heard many excuses of why the design process is often skipped, the most common one being not having time. My reply to this is "you don't have time NOT to." Seriously, spending time getting the design right, just like spending time getting the requirements right, will always save you much more time over the longer term than it will cost you in the short term.

To rectify a design fault can be costly, but to rectify a source code fault is costlier still. The later in the software development lifecycle you find a defect, the costlier it will be to fix. So one way of looking at the need for design is to reduce the costs of defects that will be found in the implementation and testing phases (finding a defect in the testing phase is the costliest of all).

By spending time designing, you are actively trying to reduce the number of defects that will be found in the later stages of the software development lifecycle. You are also mitigating any risks by actively seeking out a working solution, rather than proceeding regardless, only to find later on that something is not possible, or must be compromised.

Design can reduce the risks and costs to your software project.

Benefits from adopting software design:
There are many benefits to incorporating design into your software development lifecycle. Here are a few examples:

• Communication - the proposed solution is visible to the team and all project stake holders, and so everyone has a clear idea of what is required.


• You can find problems with the solution before you start the implementation stage, where re-development will be far more costly.


• Maintaining the application will be far easier when you have a series of design documents to refer to. This makes handing the maintenance of the application over to another team or third party much easier.

Conclusion
The design process is crucial to the success of any software development project. It forms the central communication document for the development team. It reduces the risks and costs to the project. It helps to manage the complexity that is inherent to the development lifecycle.

The positive benefits of social media

Media distortion of the negatives
I am sure we've all heard the negative news stories relating to social media, especially within the workplace. No matter how unfounded or untrue some of these accusations may be, they have been widely circulated by a media that has little grasp of Web 2.0 or social media.

In an attempt to redress the balance, I thought I'd outline just a few of the positive benefits of social media, giving some examples of how I use it.

Staying up to date
First of all, as a professional software developer, I use it to stay in touch with the latest technological developments, be they related to software, social media, applications, architectures and so on. On Twitter, I follow many technologists, from a diverse range of technical backgrounds. Some are published authors and speakers. All are interesting and worth following if you have an interest in technology.

Often, I have sent a message or question to one of them, and more importantly, received a reply. This is a great way to engage with someone on a particular topic. Not only do I get to read the reply, but so does anyone else who has access to their social media channels too, so the information is circulated to a much wider audience.

Promotion
Social media can be used to promote yourself, your business or your campaigns and causes. This is something I do regularly. My Facebook and Twitter channels are full of links to my blogs, campaign and charity groups or causes I want to champion (such as PETA). I may simply link to an article which criticises some element of government legislation, I may ask a question to get others to think about the issue, I may link to a video showing animal abuse, or anything else I want to draw people's attention to.

This is a very powerful tool, and can be very effective. If you run a business or charity, you will be much more effective if you incorporate social media channels into your overall marketing and promotion strategy. Just to be clear, I am not advocating replacing your current marketing and promotion channels, but suggesting you add social media to complement your existing channels.

Spread the word
With real time social media channels such as Twitter, news and information can be spread instantly. Agencies such as BBC News and Downing Street use Twitter to great effect, to get the news out quickly, and usually before the more traditional news channels can. After all, it is quicker to type a brief message into Twitter and hit send, than put out the same story on the radio or television, which requires much more co-ordination and organisation.

The downside to this of course, is that it is just as quick to spread dis-information, whether deliberately or otherwise. This is not a fair criticism of the technology though, rather its mis-use by disingenuous people.

Power to the people!
During the Iran election protests earlier this year, many Iranian citizens were able to share their experiences to the Western world via social media channels. These were spread quickly around the Internet, and reported by Western news agencies. To spread information so quickly like this would have been almost impossible before. As long as you have Internet access, you have a voice, and more importantly, you have an audience.

And finally...
While certain sections of the media may indulge themselves by concentrating on the more negative aspects of social media, practically all of which are not related to the technologies themselves but their mis-use by human beings, we should not focus too heavily on them. With a little common sense, we can all use social media safely and sensibly.

Public Sector and Cloud Computing

Introduction
If you are not familiar with the concept of Cloud Computing, then please read my previous article entitled What the heck is cloud computing. In essence, Cloud Computing uses virtualisation technologies and the Internet as the platform for deploying applications. One of the key drivers for deploying applications to the Cloud is to make cost savings.

Private sector vs public sector
With the US and Japan already a part of the Cloud Computing public sector revolution, it was high time the UK followed suit. There is a lot of potential for long term change in the way in which public services are delivered in the UK, as well as relieving the financial burden on the tax payer.

Cloud Computing has already been widely adopted within the private sector, with many large and diverse enterprises taking advantage of the cost reductions and increased productivity that are on offer. Cloud Computing will usually involve renting a service on a pay-as-you-go basis. In comparison, procuring the service will involve having to purchase the necessary hardware, software licences and additional support, training and other operational costs. The application in its entirety will be deployed to a third party supplier, leaving the client to get on with their business. This model frees up the client from a heavy IT investment.

The story is different within the public sector, where the reputation of IT projects and their delivery has been less than outstanding. The long list of troubled IT projects includes such well known establishments as the DWP, MoD and the NHS. Even worse, is that the situation doesn't seem to be getting any better.

Cloud Computing could be a possible solution to these sorts of publicly funded IT projects, by introducing genuine transformation to the delivery of government services.

Possible incentives
The recent Digital Britain report has recommended that the UK should deploy what is known as the G-Cloud. This would allow local and central government to share centrally hosted applications. This would then lead to substantial cost savings in public spending by building a government wide Cloud Computing platform. Key savings would come from reducing the number of data centres, reducing overall IT spend (hardware, licences), and lower maintenance and security costs.

There would also be other positive side effects to such an endeavour. The creation of a single application platform would encourage the adoption of increased levels of sharing, as well as standardisation of IT services across multiple departments. It could also lead to better service delivery during periods of peaks and troughs of demand, which is critical for e-Government service delivery.

Putting the theory into practice
This theory is currently being put into practice. A role has been created within the Cabinet Office who will be responsible for formulating and managing the implementation of the G-Cloud. The Conservative Party has committed to reviewing, and possibly replacing the NHS National Programme for IT with a Cloud Computing based alternative, in the event they win the next election. If applied successfully to one such project there is no reason to suppose it could not be applied with equal success to other projects.