Comic Relief are working with 170 other third sector organisations throughout the UK to fight world poverty and tackle hunger on the basis that the world produces enough food to feed everyone, but it is badly distributed causing waste in some countries and leaving others completely without. They need 1 million signatures before June 2013 to ensure that the issue is discussed at the G8 in Belfast, currently they have 50,000.

Preparing to hack

The title of the event was ‘What happens IF we hack hunger?’  The IF campaign team had identified four issues that they wanted to tackle using technology. These were:

1. How can we convert our light social media fans to actually sign up to the campaign?
2. How can we showcase the 150 organisations involved in IF, and the different issues and audiences they work with?
3. How can we reach out and engage brand new supporters?
4. How can we make complex policy areas and G8 agendas more accessible and interesting?

In the run up to the event we ran two short internal festivals to do some basic preparation. The first festival we used to familiarise the team with IF existing online presence and spot areas for improvement. In the second festival, we broke out into four groups to look into each area, and then fed back to the rest of the team with ideas.

On the day

It was a VERY early start! We arrived at the station for the 6.27am train to London and, feeling surprisingly awake (thanks to a strong coffee) had a look through the brief and research that had been put together for our journey which provided more in depth detail about the campaign and who else was involved.

The idea

The goal is to get 1 million signatures and we desperately wanted to help IF achieve them. Once you pledge, supporters are invited to get a wristband and ‘Find out more’ (which links back to the homepage). Our concept was to make a bigger deal out of sharing the campaign:

What if the user pledged their support (via the form) and then ‘donated’ their social media presence to promote the cause? So it goes something like this…
1. The user completes their form to ‘pledge’ their support, possibly signing in with Twitter / Facebook so details are auto populated (although we would need to capture their postcode separately)
2. The user gets a message along the lines of “thanks for supporting our campaign, we really appreciate your support but we’re still a long way off.  Would you consider donating your social media presence in order to help spread the word?”
They would then be asked which channels they would like to donate, and schedule their updates (obviously with full flexibility to cancel / amend etc).

The idea then evolved with a ‘Phase 2′ stage

How about adding an element of gamification into the mix to further encourage supporters to spread the word about the campaign? We considered how to add a unique tracking tag to each tweet/facebook post (whatever it may be) so that the supporter would collect points (which we later renamed ‘clicks’) depending on the number of shares, and the number of pledges their share had generated. This would go into a leader board so that friends could compare their score with other friends/connections on social media platforms.

Phase 3

To increase engagement we wanted supporters to be able to visualise the distance their share had travelled.
After some digging, we identified the suitable technologies and how it would be done -  it was at this point we realised that we would probably need more than a day to develop it!

Regroup

After getting very excited about the concept (and exciting the Comic Relief team by it too!) we decided that we needed to break off and focus on smaller taks that could be achieved within the day. Ben and Dimith (from Clinic Ltd) paired off to work on creating a Google Maps version of the sharing map, whilst Laurie looked at putting some designs together for how the application might look to the supporter. Whilst I put together a very short presentation to demonstrate our days work to the rest of the group. Our concept presentation was very well recieved by the rest of the group and the IF team, as were the other presentations on the day. Overall the day was really enjoyable.  All three of us agreed that we had learned loads and came away with lots to think about.

We hope this great initiative gets all the support it so rightly deserves. Visit the Enough Food IF campaign to pledge your support!
 

Test Bash is an annual grassroots conference for software testers around the country to get together and share knowledge, ideas and concepts. Not only are there a number of speakers who are big names (in the testing community anyway), but there plenty of opportunities in the breaks to discuss the day’s events. Not to mention the extra-curricular activities; like a late night discussing testing methodologies over a swift half or getting up at 6am to go for a run. (Congratulations to Paul B who was the only one of us managed both of these!)

A brief rundown of the day:

James Bach - A-Galumphing We Will Go
James is probably one of the best known software testers in the world. Often a controversial and opinionated character, but that’s what makes his talks really interesting. Galumphing is an exploratory practice that likens testing to playing, in a bid to find unexpected and unanticipated bugs when given more freedom than adhering to a string of pre-defined test cases.

Matt Archer - Balancing Test Automation Techniques
Matt used the example of boiling a frog* to illustrate the need to adapt and react to your environment. He explained the polar extremes you can go to when it comes to automating your tests and stressed the importance of choosing the right automation method for your project.
( *No actual frogs were harmed in this presentation)

Seth Eliot - Do It In Production – Testing Where It Counts.
Seth has been a Lead Tester on a number of projects at Microsoft, and previously at Amazon. He showed us how huge companies such as Microsoft, Amazon, Google and many more employ TiP techniques on a regular basis. They use powerful distributed servers to analyse every aspect of their users’ journeys through the system, monitoring everything from page load times to popularity of new features. Even going as far as pulling the plug on entire LIVE data centres to simulate disaster recovery. A terrifying thought for most software teams!

Amy Phillips - Managing A Lean Test Team
Amy shattered the myth that best practices are always the best practice. The main points that I took away from Amy’s talk are that good communication is essential and simplicity is often the key when it comes to documenting a project. For example, your test strategy that may have been a hefty document could be replaced by something as simple as a diagram on a whiteboard. All great ideas that if we adopt then we can spend more time doing and less time writing.

Stephen Janaway - A Tester’s Hierarchy of Needs
The first talk of the day that stepped away from how to test and concentrated more on why we test. The answer in this case is not ‘to find bugs’. Stephen explored what motivates us as testers. How we can not only work better in our own team but alongside the rest of our colleagues. Just below the peak of Stephen’s ‘Pyramid of Needs’ is “The business consults, relies upon, and values testers”. I found myself wearing a slightly smug grin at this point.

Lisa Crispin - Minding Your Own Business
Lisa explained why testers should be involved at the very beginning of a project and the importance of understanding the end user’s requirements if you want to make sure a feature will solve the business problem as intended. This results in a more detailed specification and hopefully less ‘undocumented features’ during development. Not to mention a better end result and a happy customer!

In the words of my own Test Manager, “If testers aren’t involved from the beginning then all we are confirming is that the wrong solution has been developed correctly”.

Huib Schoots - What Testers Can Learn From Social Sciences
The theme here was that building software is really about people. People fix problems for other people, technology is simply the means by which this is achieved. So it would make sense to study the social sciences. An understanding, however limited, of anthropology, sociology, psychology, and other big words, can only give us more understanding of what people want, why they ask for it, and how best to meet their needs. It also helps us to identify patterns in how we think and pitfalls that can make us blind to the things we are testing: problems can hide in plain sight if you’re not looking for them.

Bill Matthews - Context-Driven Security Testing
Bill gave the advice of “Think like a hacker” when it comes to building and testing security in your product. You first need to list all of the different ways someone could exploit your system before you can defend against it. And he suggested some helpful ways of mapping out your data flow to help identify potential holes in your system.

Tony Bruce - You Messed Up. Your Code Is Terrible.
Tony gave a great talk about the contrast in attitude seen among testers. We can be seen as negative people who spend all day picking faults with other peoples’ work, but it’s important to remember to have a positive input too. The trick is to keep a balanced view on everything. Try to stay positive for the sake of morale in your team. If something negative needs to be mentioned then do so – but in a way that does not offend or put others down. I’m lucky enough to have never worked anywhere with a serious blame culture and keeping that balance is something we do very well at Technophobia.

A series of 99 second talks

The concept of a 99 second talk is that you have enough time to get your point across, but it’s just a short enough period of time that you have to do so very concisely.

Among the big names and willing volunteers, Test Bash was treated to a double helping of Technophobes here.

I talked about the identity crisis that I’m having at the moment (whilst dancing nervously round the stage). Now that testing is no longer a last minute thing, and testers are getting involved in software before any software even has been written. Am I still a tester if the thing I’m testing hasn’t been built yet?

My colleague Paul B’s talk was on an old term that might still have some currency: the Software Crisis. The term was coined 45 years ago (in the software Stone Age) and rarely used now but does this mean we’re no longer in crisis or just no longer talking about it? Are software development methodologies just various ways of managing crises?

Did we learn anything?

Well of course we did!

Really? Prove it!

Well... on our first day back in the office Paul B had to investigate the permissions model on a project and took great delight in citing James Bach’s ideas about exploring a phase space with multiple degrees of freedom and exploiting Ashby’s Law of Requisite Variety.

I have been spending a lot of time on performance testing at the moment, so I’ve already suggested we apply some of Seth Eliot’s ‘Testing in Production’ ideas. We may not get to the point of actually using them in production, but the methods for gathering metrics and what to do when you get them can be applied to internal and User Acceptance test environments to help us spot bottlenecks or improve the product.

Some of the brightest and biggest brains in digital work at TP Towers. Our best asset is the people we employ. They’re smart, forward thinking and brilliant at what they do.

Our staff live online, tracking down the latest technologies and learning new things every day. Call us obsessive? We’re guilty as charged. All that enthusiasm and know-how goes straight back into our work, producing the best possible web applications for our clients.

This month one of our Technical Architects, Ian Moore, will be taking to our Twitter feed to answer your questions. Most recently, Ian has been working on the development of Substeps; an open source BDD framework that can be implemented and executed by team members with limited technical experience.

Ian will be taking to our Twitter from 14:00-16:00 Friday, April 26th, to answer your questions. Simply Tweet us to @WeTechnophobia using the #AskTP hashtag.

We also took video evidence.

None of us are at all surprised at the demise of these companies, to be honest I was surprised that they had managed to last quite so long.  Nor was it a surprise that each of them blamed online retailers like Amazon for their failure. 

* A sign in a Jessops' shop window

This sign seen in the window of the Liverpool branch of Jessops sums up the problem.  Not that international organisations like Amazon have the ability (and will) to move profit around the world to places with lower corporation tax, but the fact that they blame their customers for shopping at Amazon.

This feels like dinosaurs shaking their fists at the birds swooping above as the waters rise around their feet.

As Aden Davies so nicely put it:

A Tweet from @Aden_76

The ability for a business to change is the key.  Darwin's theory didn’t say that evolution was ‘the survival of the fittest’, he said it’s ‘the survival of the most adaptable’.  A highly tuned, efficiency maximised process won’t help when people stop wanting the thing that it produces.

These retailers have failed to recognise and react to (or predict and lead) how consumer behaviours and preferences are changing.  They have stalwartly stuck to their existing business models and processes, desperately clung to their dwindling sales, while others adapted and changed.

Investing in understanding how the changing (digital) world will affect your business isn’t something that you measure against an ROI.  The return on this investment is that you get to stay in business in a couple of years time.

*picture source and credit: https://twitter.com/conalfz/status/291449379406090240/photo/1

The general public are becoming more and more aware of online security pitfalls and expect the businesses that they are sharing their details with to keep them secure, that sensitive information is kept private and services are not interrupted.  Those organisations that fall short in living up to these expectations risk suffering from a lack of customer trust that ultimately results in fewer sales and hits the bottom line.

Security evolution

It is hard to miss that more and more people are using the internet for everything from shopping to enjoyment. We are constantly prompted for credentials and information; the internet is just one big form collecting information.

In the early days of the rise of ubiquitous usage of the internet, there was a lack of understanding about what was actually going on with the information being requested and what the implications of it not being collected correctly may be.

But now the general online public, young and old, have been educated to look for the tell-tale signs of a ‘secure’ connection when entering any sensitive information. They check that there is a padlock in their address bar and that they should not simply select links in an email but copy and paste them to prove their origin.

This is a good start however, some sites still suffer from deeper more inherent issues such as how they are storing the information once it has been ‘securely’ transmitted.

A primary example of this is access credentials; most importantly your password. There are plenty of sites out there that store your password in plain text, and when they offer a password reset functionality, generally expose their lack of security by sending your password in an email.

This type of practice has been going on for some time and only until recently it has been exposed with large brands such as Tesco, Sony, LinkedIn and Play.com to name a few being highlighted in the press for either having poor security standards or by being breached and having credentials released.

In addition to the security of passwords, it is also important to be aware of other subtle ways that an online service can expose information or be used to cause disruption. In the case of password resets, it may be possible gain information about a user or even cause them a denial of service.

Take for example that you know someone’s email address and you enter it into a site’s password reset. As soon as it says “we have sent you an email” as opposed to “records for xxx@xxx.com were not found” you have found out that user has an account. This may seem trivial but in some cases could be detrimental depending on the service that the site is offering.

In some circumstances, if an email address is entered, found, and the password is instantly changed and mailed to the user they have effectively locked the user out of that account until they receive the email and retrieve the new password. This could cause significant disruption especially if done on a regular basis.

Identifying the problem

There are a number of problems that face companies in light of the security implications. The first problem is that that there is no foolproof way of completely securing a system that is exposed to the internet however, it can be made more difficult for unauthorised parties to access.

In some cases, businesses are not aware that they even have a problem. This may be due to either a lack of understanding of their systems or that there has been a false representation of security put in place by regular penetration testing that won’t expose such vulnerabilities or leaking of additional information.

In some cases businesses find out when it is too late; either being exposed by end users via social media or via other websites or forums. The damage caused to brand reputation impacts directly upon transaction and profit levels.  Examples of this include when Tesco was exposed on twitter and Plain Text Offenders, a site dedicated to exposing sites that are known to store passwords in plain text.

Once aware of the problem, businesses have the challenge of making changes to their existing system. This may not be as easy as it may seem as the system that requires the change may be legacy systems, line of business or there may simply be a lack of funding available.

What can be done?

The risks surrounding making changes can be mitigated by taking a considered and phased approach that is well tested. In the case of passwords that are already one way encrypted, security might be further enhanced by an additional level of security using a salted hash and a different ‘slower’ hashing algorithm. Using a salted hash and an algorithm that is more CPU intensive and as such slower to compute makes decrypting passwords tedious for the hacker as it will simply take longer to break the passwords using rainbow tables and high end GPU’s.

When changes are made to authentication systems communication with the end user is vital. Keeping the user informed will ensure that they continue to trust a brand and reinforces the genuine security concern the company has for its customers.

The lack of funding is a business problem and a considered business case needs to be undertaken to understand the financial risk of damage to the brand against the initial cost of the transition.

Quick on the uptake

It's hardly news that mobile, tablet and smartphone use is on the increase; there's a huge surge in mobile uptake globally, with some countries seeing the majority of their online activity now being via smartphones or tablets.

If you look at Mary Meeker's internet report there are nearly 2.5 billion people on the net, and over a billion of those with smartphones or tablets. Not only are there more people online than ever before, but they’re using their devices for longer. 

Two years ago, Mary predicted mobile web browsing would surpass desktop web browsing in 2015. The latest report now predicts the combined smartphone and tablet install base is going to outstrip the desktop PC install base within the next 6 months.

As far as growth goes, three years ago, 1% of all internet traffic was from mobile devices.  It was over 10% by part-way through 2012.

So, massive uptake in people getting online via mobile devices.  Also a big increase in the type and maturity of the devices people are using to get online.  That rapid growth and device maturity is enabling different user behaviours; users aren't just using the mobile web to visit websites to look up contact details anymore and mobile browsers are now much more feature-complete. 

It will continue to be essential that companies consider context specific content and the information architecture of their mobile sites, but it’s not enough to stop there - there needs to be an ongoing industry reaction to users expectation that their mobile browsing experience should be able to offer context-specific and device-appropriate functionality that isn’t artificially limited by poor design or development decisions.

Being Responsive

This challenge in how users are now consuming web content and carrying out online transactions is being addressed through Responsive Design.  Responsive design is an approach to designing websites that create interfaces that adapt the layout to the device and context in which they are being viewed.  Rather than trying to detect a specific browser/device combination, the site is designed to adapt and flex irrespective of the size, shape or aspect ratio of the device on which it is being viewed.

Previously this challenge was addressed through Graceful Degradation (making a traditional image-rich, desktop style site and gracefully removing the parts that phones couldn’t cope with), then through Progressive Enhancement or Mobile First approaches (starting with a very basic mobile site, then enabling features as mobile devices state can cope with them); however the startling rate at which mobile devices are gaining features, as well as the accelerated rate at which users upgrade their handsets mean it’s no longer necessary to design expecting failure / lack of features.

Responsive design was - rightly - one of the most important web trends at the end of 2012.  However, while Responsive Design is now recognised as essential to the future of mobile web, it’s really only recognised by the web industry. There are still a huge number of fixed-width, designed-for-desktop websites that have a lot of catching up to do, to properly accommodate the way their users are trying to access their sites and services.

This terrific acceleration of mobile adoption, as well as the improvements in device maturity, mean that while there's still a lot of work to do to bridge the gap between what can be done on a web page via a traditional browser and via a mobile browser, responsive design - rather than graceful degradation - must now become the focus to make non-mobile sites work on mobile devices.

Along with greatly improved mobile interfaces, the introduction of retina displays on multiple devices will have an impact too.  Pixel densities and screen resolutions are increasing.  This has led for a push to update imagery to take advantage of retina displays; websites are regularly being scrubbed up to look at their very best on the latest devices. Unfortunately, that’s limited thinking.

In the early days of the web, websites were kept light because modems were slow; big, heavy images took forever to download.  While bandwidth speed is no longer an issue, what has become an issue is the monetisation of mobile data.  The data tariffs that users are subject to, now has to be a design consideration when delivering the content that users expect on mobile devices. 

The second problem to consider and overcome is that mobile service providers are now regularly caching frequently requested content at the mast and delivering degraded image quality to users; quicker, but it takes the quality control out of the hands of the team creating the site.

Both of these things have an impact on the considerations that need to be made when designing and building websites and mobile apps.  The work of groups like the Responsive Images Community Group (@Respimg on twitter), who are looking for ways to seamlessly deliver alternate image sources based on the capabilities of the device through markup is going to become increasingly important.  Their discussions and work are currently informing the HTML Working Group with an aim to influence the HTML5 standard.  However, until such time as their work is adopted and implemented, site design and architecture needs to consider data and bandwidth charges again, just like in the slow old days.

My personal opinion is that - rather like cookie law compliance - it should be the responsibility of the browser to give the user the choice of the quality of image they want, and for server-side code to be able to transparently respect that request, but until that time, it needs to be a design consideration. 

What about apps?

Native apps aren’t going anywhere.  Thankfully the world is beginning to move on from companies creating apps just for the sake of having an app, into a place where there’s a clearly understood separation between what should be delivered as an app, what should be delivered as a cross-device web solution, and what needs to seamlessly cross both - making good use of server-side solutions.

Expect to see a lot of convergence between web solutions and native apps this year, as companies look to offer their transactional capability in ways that allow you to benefit from best features of a mobile device (Receive coupons as you arrive in shops, special offers for restaurants near you etc) while not forcing you into using an app (how annoying would online grocery shopping be if you couldn’t switch between tablet, website and phone without having to start your shopping order again?).  This shifts some of the emphasis back to server-side solutions for reasons of security as well as continuity.

None of that is great news for HTML5 frameworks for building apps, which remains limited in its ability to deliver secure solutions - particularly around offline storage - for enterprise applications.  The expected behaviour of the app needs to inform the selection of the development framework to at least the same extent as the platforms on which the app is to run.

2013

So, 2013 will see an increased focus on Responsive Design for those organisations that haven’t yet made that step.  This trend isn’t slowing in 2013 at all, as each industry begins to become aware of how their users are trying to use their sites.

Similarly, 2013 will see an increase in companies looking for native apps that work alongside the transactional capability they offer on their websites, enhancing their offering through the features of the device.

This year, we will be continuing to work with our clients - both old and new - to find ways to design and deliver responsive sites that offer a great user experience, across an ever growing number of devices - and to do so without burning up peoples monthly data allowances, until such time as both browsers and mobile providers catch up.

We’ll be advising and working with the most appropriate app framework to deliver the best solution while ensuring security remains at the heart of any integration between client and server, providing a frictionless experience no matter how, or from what device users choose to access the systems. 

Just as responsive design has been borne out of the enormous growth in mobile uptake and is itself a response to user demand, so we’ll continue to adapt and select tools, frameworks and approaches that will allow us to continue to respond quickly and effectively to the rapidly changing expectations of users.

image CC courtesy of http://www.flickr.com/photos/ebayink/6816581064/

So what is it open or free?

"Free Software" is a movement about the liberty to adopt, adapt and change rather than any opposition to people benefiting financially from their hard work. The common shorthand is “free as in speech, not free as in beer", and the emergence of this term, and the burgeoning movement behind it, presented a very significant change to the way that people thought about software.

“Open Source” is a particular way in which people have produced ‘free as in speech’ products that allow for their software to be implemented by others with the request freedom to make alterations to tailor or improve, while they still charge for updates, support, premium features etc.

Many Open Source projects are still rooted in code originally written by loosely federated groups, widely spread, and collaborating together in interesting ways. This can mean large scalable collaboration solutions but is more likely to be a collection of loosely federated services that were the ones the participants felt most comfortable (and therefore most productive) using at the time such as wikis, forums, mailing lists and all important data bundled in with the source code in an open-access distributed revision control system.

The use of these more free-form tools promotes conversation and builds these groups into teams all working to one goal, better software. The other advantage of these tools is they have a very low barrier to entry making it easy for new team members to adopt them or for them to be replaced when they are no longer fit for purpose.

The feedback loop

Another key success factor in a lot of Open Source is frequent releases, these and the transparency of the systems in use, leads to a very short feedback loop; the team releases a new version and real users very quickly obtain the latest version, try it out, and can raise defects, suggest enhancements or just develop them themselves. This high speed feedback loop that delivers real, tangible, features to the user very quickly, as they are created, is where we can see things starting to line up with agile delivery practices.

There are a number of agile methodologies, including Scrum, DSDM, XP, Kanban and others. In general, they share the common characteristics of being low in ceremony, high in teamwork and focused on delivering value early. Most but not all are iterative, they lay out the teams differently but the goal is working software as early as possible, shortening that feedback loop. The vast majority of software that supports the agile ecosystem - story tracking tools, continuous integration tools, distributed version control systems - is Open Source. This  and the emphasis on feedback, collaboration and iteration, creates a virtuous circle, where the processes in use enhance the tools that are delivered, and the tools are used by the kinds of people that understand the processes.

Risk should be analysed, quantified and mitigated, but often Open Source and/or Agile, gets labelled as "risky" without real analysis or understanding which can be an uphill battle to introduce Open Source, despite the demonstrable benefits. Use of Open Source in general reduces vendor lock-in and if agile processes are introduced into the same projects, you can give yourself the flexibility to change components mid stream and further reduce that dependence on particular vendors.

Cheaper and simpler procurement

One thing that is changing rapidly and should only see a rapid increase in adoption is agile approaches to procurement.  With budgets being tightened everybody including the government are moving heavily toward lighter weight frameworks and other less costly methods of engaging with suppliers.

The most exciting trend in this space is the expansion of ‘hack days’. These started out as a way of getting a wave of momentum into a project and probably an open source one at that. They came into corporate culture via events such as Atlassian’s ShipIt day (previously known as FedEx day, but the shipping company objected). Now more organisations are using hackdays and competitions to generate ideas and test suppliers. Alongside this in the public sector hack days have been used as consumers of open data to seed the landscape with projects and ideas that consume that data.

For the price of providing space, food and internet connectivity you can gain the ability to actually watch teams run an agile process and use open source tools to produce a small set of functionality. This can then be measured for quality, especially if you provide a test suite that you have pre-populated for them to work against. As with all procurement processes, just because it seems cheaper and simpler does not mean you don’t need experience to do it correctly. Just like getting an early strawberry crop in a polytunnel it takes an understanding of how to get the conditions just right.

In conclusion

The collaborative, transparent nature of agile delivery, combined with the benefits of Open Source software and cheaper more agile procurement, opens up a brighter future for public sector IT projects, where iterative enhancements can be layered on top of each other to improve user experiences and realise efficiencies. By introducing realistic analysis of the benefits and risks of these approaches, we can work to educate people that it is possible to have solutions that are cheap to build, cheap to run and that deliver to the end users on an ongoing basis, without tying ourselves to vendor lifecycles that could limit flexibility.

A colleague, Rory Gibson, recently spoke to a conference about Open Source in the Public Sector and I am grateful to him for the use of some of his content (that he released under an open licence).

Here's why I think so:

1. Microsoft's twenty year dominance of the enterprise operating system market is under threat.

A few weeks ago KPCB analyst Mary Meeker released the latest update to her regular 'Internet Trends' presentation. In it, amongst many pertinent insights, she showed the following chart:

This shows two things in stark detail: firstly, just how dominant Windows has been over the last 20 years; and secondly how that dominance is now coming under sustained threat from Apple and Android. Of course this chart shows the whole market - consumer and enterprise - and also doesn't show how the market for operating systems has expanded overall, as new device formats have entered the market. And, despite what this graph implies, within the enterprise Windows' dominance still remains very much intact. The question is whether the the adoption of other operating systems will ‘bleed over’ from the consumer sphere into the enterprise. Several people think it will and the fact that Microsoft's response to this challenge - Windows 8 and Surface - is not selling as well as expected lends their view some credence. As Cormak Foster rightly points out though, Microsoft have a track record of cheating death.

2. The 'Bring Your Own Device' movement has now gone mainstream.

A major contributor to the challenge on Windows’ dominance (or the infection vector, as Microsoft might call it) is the Bring Your Own Device (BYOD) trend. According to research firm Ovum, some 70% of 4000 employees polled said they use their personal mobile devices to access work data. I think partly this is due to the desire for mobility, but also that mobile consumer technology is demonstrating new ways of working to a huge number of people, with new behaviours in messaging, task lists, collaboration, note-taking, etc. This is only going to continue, with the usability gap between what companies offer within the corporate firewall and what employees experience outside it widening for a large number of companies.

One caveat though: as the link above attests, the Ovum research also shows that a huge amount of BYOD activity goes unmonitored by firms, which is a scary prospect for IT departments to say the least. Unsurprisingly, as Michael Dell recently explained, this is a large component of Dell’s (and by extension Microsoft’s) strategy: to counter the BYOD movement with devices and software that provide a consumer-like experience but without giving up corporate control.

3. The 50 year dream of the paperless office has finally arrived.

It may be, though, that ‘consumer-like experience’ will not be enough, because there is a deeper trend at work here. One thing Mary Meeker didn't discuss in her slidedeck I think shows the real underlying threat to the current Microsoft Office paradigm - printer sales appear to be in terminal decline.

This is very bad news for printer manufacturers certainly, but I think it's also bad news for Microsoft, as so much of the ergonomic logic behind their Office software is predicated on paper. For instance, how many people still need to design document layouts and do mail merges? And are spreadsheets really the best way to store, analyse and visualise data? New paradigms are emerging for much of the activity that was formerly done by Office, although it has to be noted that the transition (if indeed a wholesale transition occurs) is going to be painful. Horror stories are already starting to emerge of organisations who replaced their laptops and office software with tablets without sufficient planning and support. Microsoft Surface is squarely positioned to be a hybrid - enabling new kinds of interaction whilst still allowing familiar Office interactions. It remains to be seen whether such a halfway house is going to be successful. In a sense, Microsoft have enjoyed such a monopoly that they have never had to properly move beyond the initial computerisation of office tasks - which were all based on paper - and Office 365, is still Office whether it’s in the cloud or not..

4. Venture capital is starting to flood into the B2B sector.

It has been a pretty difficult couple of years for venture capital in the digital consumer market. Big IPOs from Facebook, Groupon and Zynga have proved unable to maintain initial optimism, and have indicated to many that there’s a tendency to overvalue the market. The enterprise market on the other hand seems more attractive as a slew of adolescent companies start offering high performance cloud-based productivity and data-analysis software at a fraction of the price of traditional solutions, and are now gunning for a market dominated by Oracle, SAP, Microsoft and the other incumbent mega firms. Companies such as Platfora, Tableau, Box, Cloudera, Datahero and many others are in the vanguard, alongside established disruptors like Salesforce.

Of course there is going to be a lot of acquisition and consolidation, but there will also be a lot of innovation, much of it focussed around putting new business tools into people’s hands across all available interaction platforms.

5. New hybrid hardware is proliferating.

Two and a half years after the release of Apple’s iPad, the market is awash with devices that try to combine the portability of tablets with the familiarity and easy text entry of laptops. All the major vendors are trying to figure out what works best - whether the keyboard should be detachable, whether it should be in a lightweight cover, whether it should flip over, whether the device should even have two screens, etc.

And it’s not just tablet/laptops in which new hybrid interaction models are being experimented with - there’s a new format of desktop PC known as ‘All in Ones’ in which the all the computer’s innards are housed in a touch screen monitors. This means that in some devices the screen can be removed and used as a large tablet, but, perhaps more interestingly, in devices such as Dell’s XPS One 27 the screen can be folded nearly flat in order to perform functions that require touch and gesture-based interaction at the desk.

All of these different formats encourage people and firms to really think about how they want to work and look at what the possibilities are. This in itself will drive change.

6. Blackberry is re-entering the market.

This may be a long shot given RIM’s performance over the last few years but I think if they hit their intended window for re-entry in early 2013, they will arrive a good time, as the market is in flux for all the reasons given above. If their long awaited BB10 range delivers compellingly designed experiences with high levels of security, but using a paradigm that moves away from the paper-derived interactions of Office, then they may still have a big role to play. Goldman Sachs and others appear to think so as they have recently upgraded their ratings in anticipation.

So what can we take away from all this..?

Businesses need to be flexible if they want to reap the rewards of greater productivity that are promised, and, just like the huge productivity gains produced by the 'scientific management' movement a hundred and twenty years ago, at a fundamental level it comes down to speed of interaction: If there are functions that can be performed best sitting down at a desk using a mouse and a keyboard then a standard web interface may be ideal, but if it's quicker to sort through things with your fingers then perhaps a bespoke touch interface is worth investing in for that particular function. And perhaps it should be written in HTML5 in order run on multiple devices, or perhaps it should be written to run natively for one or more operating systems. Perhaps certain data or interactivity is best incorporated into existing software via a plugin or API calls, or perhaps it's best in its own bespoke application. Perhaps certain users need to do some things from a smartphone or tablet whilst away from their base. Perhaps the fastest way to get work done is to have several people sitting around a single large touch screen and working together...

The upshot is that most enterprises have a lot of design work ahead of them to make the best use of what is now possible. And this necessitates three crucial things:

Firstly, software that concentrates on the user, their competencies and needs. That is software that is produced by a design process that seeks to deeply understand how people use it, and that continually revisits its assumptions to check that they still hold true in a changing environment.

Secondly, development processes that are both efficient and extremely flexible. Where changes can be made quickly if new ways of working need to be explored. And where whole systems can be tested automatically when changes are applied to ensure their integrity - and across a range of devices.

And finally, and most importantly of all, the will to experiment: to bring diverse groups of people together - including end users, the IT department, managers, HR, external consultants and vendors - to explore and learn, and ultimately design and make decisions about, how the business is going to use emerging technologies to make the firm work better.

Here is the story of the day.

I was more than happy to be the second speaker on stage, following on from Tariq Rashid of the Cabinet Office IT Reform Group.  Tariq's presentation, which outlined the current state of UK public government IT spending and the plans to make the processes leaner, was extremely interesting - all the more so since it outlined a number of the same themes in my own presentation.

The presentation I gave, entitled "Intersection: Combining Open Source and agile delivery" is based on one simple principle; that while Open Source is beginning to be more widely used in the public sector, and agile delivery techniques are gaining traction, there's a lot to be gained by combining the two and delivering low cost, flexible IT solutions in an iterative way.

Overall, my impression of the conference was of a feeling that we're "almost there" with the usage of Open Source in the public sector; the benefits are understood, if not always by the top level decision makers.

The big areas that need to be fixed (and this is not only my viewpoint, but that of the Cabinet Office Reform Group) are procurement and delivery, and the difficult relationships between departments and suppliers.  If we want to reduce costs and produce solutions that really deliver to our end customers, Government need to find ways of working with lean, focussed suppliers - and they need to create relationships that are based on mutual trust, not contracts designed to apportion blame in the case of failure.

There are real opportunities for SMEs, especially those with experience in the agile and Open Source arenas, to make in-roads in the next few years - working closely with their customers, in a way that's designed to produce quality software, not hostile customer relationships.

My presentation notes and slides can be found on my account at GitHub - it seemed to make sense to release the slides for an Open Source presentation as Open Source themselves.

Account Exec Niki Davies on the Great Wall of China

It’s no secret that Technophobes love a challenge; especially when we’re raising money for causes that we believe in. This year, Account Executive, Niki Davies has gone above-and-beyond for a cause very close to her heart: Bowel Cancer UK.

Just over a year ago, Niki lost her friend James, at just 28 years old, to bowel cancer. Since then, she has dedicated her spare time to raising funds in his memory. Just this year alone, Niki has completed the following feats:

Sunday 27th May 2012 - Edinburgh Marathon 
Saturday 1st September 2012 - Paddle the Channel
Sunday 16th September 2012 - Great North Run
14th - 25th October 2012 - Great Wall of China Trek
Saturday 28th October 2012 - Worksop Half Marathon

Rounding off a year of hard work and fundraising, Niki, her brother, and two friends, headed off to China for their biggest challenge to date - a 5 day trek along the Great Wall. In true Technophobe style, Niki kept our office updated via the internet (we can find it in the most remote places!). I managed to grab a chat with Niki on her return, here’s what she had to say:

“Walking The Great Wall of China was one of the most amazing experiences of my life and to say I’ve done it is incredible.”

“We walked for an average of seven hours per day, using the towers of the wall as our milestones. At night, we stayed in nearby villages; where we were really welcomed by the local people, who kept us entertained with traditional Chinese music, food and activities.”

“The wall itself is absolutely beautiful. It’s incredible to think how it was built. Some parts of it are impassable which made the trip even more eventful as we got to go off-course. There were times when we were crossing tiny ledges, on our hands and knees, over sheer drops, which was pretty intense, but it was such an amazing experience.  In fact, it made the ‘safe’ bits of the wall seem almost normal!’’

It’s also worth pointing out that Niki arrived back in the UK at 2am Friday morning, and was in the office, bright and breezy as ever, by 9am the same day to start work. Two days later she, and fellow Account Exec Ellie Mosely, ran the Worksop Half Marathon where she beat her personal best time by twenty minutes!  All in a week’s work for our Niki!

So far, Niki is 95% of the way towards her 2012 fundraising target of £3,500 - so if you would like to help her hit the target, and celebrate a truly incredible year - please do so - any donations will be very gratefully received!

Well done Niki - Technophobia’s Iron Woman!

As I explained in my previous post, part I, the main problem we encountered with using Cucumber and Java to implement BDD was the impact upon the development team of writing the significant amount of ‘test’ code that is required, in addition to implementing the actual solution.

A Cucumber Alternative

It was clear to me that the impact on the development team could be reduced by providing a better framework that enabled the test authors to implement a greater proportion of the tests themselves, independently of the development team.  I built a proof of concept which gained the support of test and development colleagues here at Technophobia.  From that starting point, we developed the Substeps framework, specifically to:

• implement BDD using natural language as close to Cucumber’s Gherkin syntax as possible
• reduce the amount of developer effort involved in implementing step implementations
• providing a way for the QA team to easily execute tests
• provide as much help as possible to the QA team to be able to write the tests.

Substeps provides a unique capability amongst java based BDD frameworks in that it is possible to construct nest step definitions (The Ruby version of Cucumber does support this, however these nested definitions are in line with the scenario definitions and hence adversely affect readability by anybody non-technical.), i.e. substeps!  In addition there are some 'pre-packaged' step definitions that the Technophobia Substeps team have developed and made available that can be used alongside bespoke implementations appropriate to the project.

Here’s a snippet of an example scenario to illustrate this:

Using the Substeps framework, the first line could be broken down into the following substeps:

Step definitions are composed of sub-steps, essentially the same as a step but with a bit more of a technical nature. Each sub-step correlates to either another step definition, or a step implementation defined in Java. In this way it is possible for our QA team to assemble complex scenarios from smaller, re-usable building blocks and in addition define their own reusable step definitions as appropriate to the project.

The diagram below illustrates the various layers and building blocks of a Substeps test.

The intention is that the smallest unit of these building blocks, the step implementations, can either be found in predefined libraries or are created by developers specifically for the needs of the project. Substeps promotes the reuse of such libraries, the simplified example above is using the “webdriver-substeps” library of step definitions, which is designed to control a web browser and test the functionality of a web application. As with Cucumber step definitions, there is no restriction, beyond the restrictions of Java, of what a step implementation or a Substep library can do.

Test execution

Since scenarios are assembled from step definitions, which in turn are composed of existing step implementations, it is possible for test authors to execute the scripts themselves immediately, without necessarily requiring additional developer input to implement anything*. Test suites can be executed against multiple environments, with the same tests used across each one, with a configurable parameter determining which specific environment to target.

* Note. In the early stages of a project, some bespoke step implementations will almost certainly be required.  As the libraries both internally on the project and the open source libraries mature the need to implement bespoke implementations diminishes.

Integration

Full suites of tests can be executed in an automated manner using Maven or Ant and can be easily integrated into standard CI tools; this produces an HTML report of test success or otherwise, allowing users to easily drill down to the source of any problems.  A sample of the execution report can be found here.

Glossary

For Substep test authors to be successful, they must have an understanding of the sub steps that are available for them to use, an appreciation of the building blocks at their disposal. To make this easier and to encourage re-use of existing substeps, an HTML report can be automatically generated for a specific project, documenting the substeps that are available, both in included libraries and bespoke step implementations for the project. 

An example of the Substeps glossary report can be found here, this is the report generated for the webdriver-substeps project.

When the glossary builder is executed against your own project, it will aggregate information from any included libraries such as webdriver-substeps, in addition to any steps implemented in your own project.  Additional information on the substeps glossary builder can be found here.

Impact

The adoption of Substeps as our BDD framework of choice has dramatically reduced the amount of developer effort required to implement the tests.  In my previous article I described the user of Cucumber to perform BDD tests on a J2EE application and the significant developer effort that was required for the step implementations:

In a subsequent phase of the same project, we decided to use Substeps; the following graphic illustrates (with an approximate scale) that significantly less step implementation Java code was required, and therefore, less developer effort was required.

Note, the coverage statistic is for code covered by the executing the Substeps tests only. 

The reduction in impact of BDD on the development team has allowed our QA team to take full ownership of the acceptance tests: building and executing a test that fails in advance of the final functionality being available, a genuine, test first approach.  No longer is there such a great dependency on the development team to build step implementations.  Naturally, this has lead to an increased level of quality and a shortened development cycle as acceptance tests have been executed alongside the development of the actual implementation.

The future

We’re still actively developing Substeps, adding new features and extending its capabilities, there’s quite a bit more we’d like to do with it and we'd be interested to hear your thoughts on its future direction too.

On a different level, Substeps provides a practical way to build and execute high level business focussed acceptance tests. Through using Substeps and demonstrating the benefits of this approach to clients, perhaps we (as Software Engineers) can encourage more consumers of our services to specify their requirements as acceptance tests that feed directly into the test process.

Summary

The initial versions of Substeps were trialled on a few projects here at Technophobia with great success.  It has now become our standard BDD framework and through its use we are seeing significant benefits in terms of a reduced defect rate and higher quality deliveries, but without the impact upon the development teams that we have experienced before.

Previous attempts at BDD using Cucumber were simply too costly and ultimately only ever partially implemented. Substeps has enabled a practical application of BDD without being prohibitively costly.

To our clients this means greater project transparency, more robust code, shorter development cycles and ultimately reduced development costs.

Documentation on Substeps can be found at http://substeps.technophobia.com/ along with a sample project that you can download and run to see how it all works.

Substeps is licensed under the permissive Lesser Gnu Public License and is available in Maven Central and on github.

A Substeps google group has been created to help resolve any queries and to announce new versions.

In basic terms, test specifications are expressed using natural language, for example:

Given I can login in to the system
Then I can edit my profile
And I can send messages to my friends

A BDD framework, such as Cucumber or JBehave, is used to associate these sentences (or steps) with the 'test code' (step implementations) that will actually perform the test. For testing web applications this will typically involve driving a web browser automatically to use the system under test.

The benefits of having an automated test pack are clear; less time spent retesting, and higher quality software.  Using a BDD approach, however, has other significant advantages over other automated test packs.

By using natural language, the test specifications (also known as features or stories) should be accessible and comprehensible to users, business sponsors and developers alike, with the intention of removing a degree of ambiguity and error that is inherent when requirements are translated from one team to another. Additionally, by physically linking a requirement to a test that proves fulfilment, the visibility of progress and missing functionality becomes elevated and apparent to all, especially the client.

Lessons in Applied BDD using Cucumber

How well does BDD theory translate into practice? Here at Technophobia, we adopted a BDD approach a few years ago, with Cucumber and Java (cuke4duke, not the later CucmberJVM) as the BDD framework of choice. Here are some of the lessons that we've learned since adoption.

1. Keep the features at a high level
Technophobia's initial experimentations with Cucumber was led by the development team and resulted in scenario steps that were too specific to the software we were using to 'drive' the web browser (selenium's webdriver):

Given I locate id "login-field-id"
Then I can enter text "username"
Then I click button id "login-id"

These steps are too low level and far from 'business friendly' to describe acceptance criteria for an application, not to mention verbose.  Judging by the number of articles on the web that address this specific problem, it would appear that this is a common problem. Features become less descriptive and less readable, any interest from business people in BDD would be taxed and lose interest.

2. Put complexity and re-usable functionality in code
The solution to the problem described above, is to hide any complexity in the implementations of the steps themselves.  (There is even a pattern (PageObject) to support this type of approach, the various operations and actions upon a web page are modelled as methods, enterTextIntoLoginField(String text) for example. The step implementations then call these methods.)

3. Give your developers plenty of time to code the step implementations
Unless your testers are skilled in Ruby or Java and can code the step implementations themselves, it is most likely that it will be the development team that will undertake this work.  In the early stages of a project, developers may have time to implement some tests alongside actual code. Using a pure BDD approach, features will already have been defined as the requirements, in reality, it has been our QA team who have translated requirements documents into features and scenarios. In the early stages of a project, with no application to test against and with just text to write, the mountain of features awaiting implementation rises rapidly.

Conclusion

The infographic below illustrates the scale of effort required to implement BDD with Cucumber. The data was obtained from a recent project to deliver a J2EE web application that surfaces information from a complex legacy database. 'Statements' and 'Lines' are two measurements that provide an indication of the size of code base.

As you can see, the volume of 'test' code required to obtain a reasonable level of test coverage is between a half to a third of the size of production codebase and represents a significant amount of additional work for the development team.

BDD is an excellent idea, business requirements can be expressed in a manner that both  business and technical people can understand, removing a layer of interpretation, ambiguity and the potential for errors. Automated tests are integral to delivering quality software and I now consider tests that operate at the functional level and from a user-perspective to be invaluable.  However, as illustrated in this example, implementing BDD using Cucumber and Java has too great an impact upon the development team, despite the overall benefits that it brings.

Now read part II to see how we've tackled these issues and developed a more practical approach to BDD and reduced the impact upon the development.