Let's drop ‘Responsive’ from Responsive Design

In a meeting a while back, a client who had their web site built on a shoestring asked me with a slightly panicked expression: is my web site ‘Responsive’? I looked at the site and squished the browser around some and saw rudimentary things happen to the layout. It didn't look great. The only answer I could give to try and appease the anxiety of said client was 'a bit’.

It did make me start to question what Responsive Design was and question all the current 'attempted' classifications around fluid, reactive and adaptive, etc. I won’t go into the detail here, but you can use the interweb to find out more :

The truth is that there is no one answer and the lines between fluid, responsive and adaptive design are blurred and ever changing in a world which is producing devices of varying dimensions and capabilities faster than people can pour buckets of ice over their heads.

Responsive Design is not an end state, it is a process which tries to deal with many challenges of building web applications that can be viewed from your phone through to your TV through to gigantic projections on one side of the Grand Canyon (should it be so lucky).

The challenges are centered around these areas:

Can User Stories be used in Waterfall Development?

If you work in the business of software development you most likely have come across User Stories. If you aren’t familiar with them, or are all of a sudden being asked to write them or deliver them and aren’t quite sure what they are, here is a brief background.

User Stories are born from Extreme Programming (XP) and Agile Development Methodologies. XP and Agile development is essentially a set of principles and practices which have emerged over the years (XP was first coined in 1999) to address with the challenges of software development and fulfill a goal of delivering working software as early as possible.

User Stories fit mainly into the requirements gathering and definition phase of software development. They are Agile’s answer to transforming what is often an onerous, expensive, confusing, obscure and inefficient process to one that is lightweight and effective, and drives the software development process towards delivering valuable software features early.

Like many other aspects of Agile Development, User Stories are becoming adopted as an industry standard way of describing software requirements.

The benefits behind writing requirements in this way include:

• Writing requirements as User Stories makes them easy to understand i.e. they eliminate technical or domain jargon 
• Writing requirements as User Stories helps validate their value to the users of the application 
• User Stories can be delivered independently and in short iterations, allowing the ROI from working software to be realised earlier 

However, because User Stories are being appropriated by different organisations who deliver software in less agile and more waterfall ways (wagile, scrumafall, etc) and don’t have all the other Agile practices in place, there is often confusion around what a User Story is and how they can be used to describe, specify and deliver a solution.

In my experience, this is often the case where an Agency or Software House (Delivery Partner) is tasked to define, cost and deliver a new build for a Client.

In this scenario, the following constraints often apply:

• The Client has a maximum budget to get the solution built 
• The Client has a massive wish list of requirements 
• The list of requirements exceed the budget
• The Client wants to know what they are going to get for their budget at the beginning of the project 

Given this starting position, the Delivery Partner has the challenge of defining and delivering a solution which has as many of the items from the wishlist within the budget constraint. So faced with this challenge, can User Stories be used to define and cost a fix priced build?

The short answer, I put forward, is yes with a caveat that User Stories go through the following steps to turn them into a scope of work that can be delivered within a budget.

The Devil of Distributed Development

There is gold in them thar hills!

Over the last six months, I have been working on a model for distributed, Agile Scrum development. This has been in response to on-going issues on software projects where development (front end, back-end and testing) is done in an offshore office. The issues have been around areas such as relationships, quality, communication, profitability and client satisfaction.

In addition to these common trouble hotspots, I work in a creative led Digital Agency which, due to the nature of the beast, presents even more challenges around establishing dedicated teams with the right skill-sets, consistent delivery methodologies, adhering to best practices and educating internal and external stakeholders into rationale behind them.  The last point around education is probably the biggest overarching challenge since if everyone knew what the right thing was to do, they would do it.

The best example of an education challenge is explaining the tax of distributed development. From a financial person's perspective distributed development is a no brainer.

"What? You mean one expensive onshore developer can fund almost five cheap offshore developers. These margins are massive! Well get on the phone to any country with a slightly f*cked economy and round up developers. Ideally it should be a country that has been oppressed by a communist regime guaranteeing optimal economic exploitation combined with a decent level of education. Yeehaaa! There is gold in them thar hills!" said fictitious Financial Person.

Cloud Talk : A walk through the clouds

Thanks @syzygyuk for hosting the EPiServer meetup.

I've uploaded my slides from my talk on the Cloud to the Cloud:

The Cloud and Microsoft Windows Azure - A Walk through the clouds from Mark Rodseth

What is Dev Ops and why is it important?

We have recently been recruiting for a new role in our company: that of a Developer Operations role, or Dev Ops. This initiative has mainly been inspired by other companies who have identified the need for a separation between Development and Operations, and the need for development skills in the operations sphere.

An example of an Application Life-cycle Process without development operations would look something like this.

The work flow would go as follows:

Cloud recipe: Standing up an Enterprise, Solr Search Server on Azure in fifteen minutes

I recently saw some Twitter activity around a new on-line Community called VM Depot. From the website: "VM Depot is a community-driven catalogue of preconfigured operating systems, applications, and development stacks that can easily be deployed on Windows Azure."

One of the VMs which caught my eye was an Linux VM with a fully configured instance of Apache Solr 4: a lightening fast, enterprise Lucene search engine built by the Apache community.

In this Cloud Recipe we will deploy a fully configured Linux VM running Apache Solr and write some C# code to talk to it.

To complete this recipe, you need the following:

• A Windows Azure Subscription. 
• Node.JS and node package manager (NPM). This can be downloaded and installed here.

You should be able to complete this recipe in under 30 minutes.

The most important part of Agile is education. Ongoing education.

Agile is a widely adopted methodology across the software devevlopment industry. The two main frameworks of Agile are Scrum and Kanban, both similar variants to each other but which both address the same set of problems with software traditional waterfall development, such as slower and more problematic delivery.

They address these problems through more collaboration across disciplines to ensure decisions are made with all relevant viewpoints taken into account, more frequent release cycles to ensure early exposure of the product to the client and the ability to adapt and change course where necessary, and a commercial structure that understands the reality of complex, software development with many integration points by agreeing to either fixed price or fixed scope, but not both.

Cloud Recipes: Building a Facebook Canvas App using Azure and BitBucket

Welcome to the first official entry into Tech-Rash's Cloud Recipes. Cloud Recipes, I hope, will became a useful reference for cool things you can do on the Cloud in thirty minutes our under.

This Cloud Recipe has been shamelessly ripped off a talk given by Richard Conway from ElastaCloud who runs the UK Windows Azure User Group. In the talk he demonstrated setting up a Facebook application in 15 minutes based on a new .Net 4 MVC Facebook Template provided in the ASP.Net Fall 2012 Update. He used BitBucket as a Source Repository and rigged up an Azure Website to Auto-publish from the BitBucket Repo. I gave it a go and to see if I could achieve in 15 minutes and I failed but did learn a valuable lesson that churning out Facebook Apps can be a very quick process.

UKWAUG Talk: RavenDb on Azure in 15 minutes

On Friday 30th of December I attended the UK Windows Azure User Group and spoke about about running RavenDB - a great NoSQL technology - on an Azure VM. Thanks to the UKWAUG for hosting the event and the other speakers for some really interesting and inspiring content. The pizza and beer went down very well too.

The other talks included:

• Cost saving Azure Solution Architecture
• Creating a Facebook Application in 15 Minutes on an Azure Web Site with BitBucket as source control
• Robot Ball Wars - A tech showdown using Sphero controlled from Smart Devices and a NetDuino with various inputs such as a Wii Remote. The showdown culminated in two Sphero balls dancing in tandem to Gangnam style which was bizzare but lots of fun.

Useful Links:

• My slide deck: http://www.slideshare.net/markrodseth/ravendb-presentation
• UKWAUG: http://ukwaug.net/ 
• Sphero: http://www.gosphero.com/ 
• NetDuino: http://netduino.com/ 

A pragmatist’s view: What is Technical Architecture and how do you do it?

As a Technical Architect in a digital agency I am often am asked what the role actually means or does. This question comes from everyone including Technical Architects (TAs) and one that is actually quite difficult to answer. The reason for this is that the definition of Technical Architecture in the real world has a very broad scope and is different in different companies, projects and from person to person. It is often becomes a religious argument what being a TA means or what the best way of doing it is. Forgetting best practices, patterns, methodologies, techniques and opinions just for a minute, here a broad view ‘what’ a Technical Architect does and ‘how’ they do it. I'll even look at why in some cases. I'll leave where and who up to you.

Dealing with a Vampire Launch: What to do when your site bursts into flames

We're gonna need a montage.

I've written about Vampire Launches in the past. For new comers, a 'Vampire Launch' is when a site or application is launched and has a brief and glorious moment in the sun but then suddenly and horrifically erupts into flames. Vampire launches do happen and when they do, an expert firefighting team needs to be deployed to deal with technically complex and mysterious issues in a pressured and emotional environment. Having been involved in a few crises in my time and watching and participating in their resolution, these are some things I've learnt along the way.

Social networks: If you build it, will they come?

Don't do what Costner did or you will fail.

Social is pretty big now, right? If you ask me what main things the next generation have which I didn't have growing up, I'd say Facebook, Twitter and Apps. It's no surprise then that businesses are desperate to get involved and use social networking to boost their profile and their profits. And while they're at it they will create a couple of apps too.

There are many different strategies to leverage social media. Some companies try to use what's already there. They will litter their web site with Social calls to action. Do you 'Like' this page about the latest innovation in washing powder? Of course I do! Which person of sound mind wouldn’t? Would you like to tweet and then re-tweet this great deal on life insurance? Did you have to ask? #Death is trending right now.

Building a Cloud Platform: Weapons of War

I've just returned home from a big development build. For the last five months we've been in a secret room racing to get version 1.0 of a cumulonimbus size cloud project out. It wasn't easy. Getting to 1.0 was a real battle because... well, you don't know! Because you weren't there... man!

Now that I am back on civilian soil and fighting off night terrors from the horrors of war, I can reflect on what went well and what when badly. This could be a book in its own right; but for this post I'm going to cover The Weapons of War - or the essential tools needed when building any product or platoon... I mean platform.

Web application development is transforming, but that doesn't mean everything has to change

The way we build web and mobile device applications is changing fundamentally. What this change is - in a nutshell - is application code moving from the server to the client. The server being big computers sitting in a data centre somewhere and the client being a modern day browser. To explain this further, let’s call the old way of building web sites as web 2.0 and the new way as web 3.0.

In the past, when web 2.0 was all the rage, web sites were built with a lot of server side code written languages such as c#, php or java. This code ran on various web server application platforms such as Microsoft ASP.Net. The code ran on the server and spat out HTML which was rendered on a browser and allowed the user to interact with the application. There was probably was a bit of JavaScript but none of which was essential to the application doing what it needed to do.

What defines a successful project?

Single Fist Pump!

A colleague asked me over coffee, “What do you do?” I sipped my full fat cappuccino and reflected on the question. Sipping coffee and reflecting go well together so I may have milked the situation a bit more than was required. 

“Hello!” he interrupted. “Did you hear me?”

It was a good question erring on the side of existential and difficult to sum up in a tweet sized thought bite. 

For a bit of context, I have a technical leadership role which can mean many things to many people - including other people in technical leadership roles. I had to dig deep and try find an answer that came from my heart and wasn’t ripped off from the Steve Jobs Autobiography. 

“To make sure we deliver projects... successfully.” I said with the thousand yard stare of a visionary. 

“To deliver projects?” he smirked. “Truly inspirational.”

Avoiding the pitfalls of joint Web Site and Web Service development

How to turn a Balrog into a puppy dog.

Developing web and device applications these days is more often than not dependant on 3rd party web services. This integration is one of the biggest culprits behind projects being delivered late and costing more than expected. I’m not talking about fully developed and functioning web services, of course; but web services developed in tandem with the web site. There are a number of reasons why developing web sites and dependant web services together can cause severe delays in and over-spends in project.

RavenDB Vs SQL - A follow up

The fight they were all waiting for

This is a following on post from RavenDB is it all it’s cracked up to be. A few have commented that to provide any meaningful interpretation of the load test they needed to know more about the SQL implementation which is fair enough. So, here we go.