Photo of Jamie & Lion

The personal site of Jamie Knight, a slightly autistic web developer, speaker and mountain biker who is never seen far from his plush sidekick Lion. View the Archive

Topics: Autism Development

Getting started building a software project

I started writing this to help out an organisation I was informally advising. Just a bit of input really. I figure, by posting it publicly its open for comments and updates. It also means I can find it when I want to refer to it in the future.

So, lets assume, your an organisation and your writing a funding bid. What options are there for getting software built?

For the purpose of this article, lets assume there is no off the shelf software you can use. So you need to building something from scratch?

What are the options?

Two decisions, many combinations.

In my opinion, when building software there are two decisions you have to make early:

1: Where are the team coming from? What structure will they operate within?
2: What methodology will the operate under?

Those two decisions are intensely interrelated. But before we dive in, a disclaimer:

This article is incomplete and probably biased. It’s just the options I am aware of, its intended as a handy starting off point, not a full guide.

Business Structure.

In my mind there are three option for gaining the efforts of a group of developers:

1: hire
2: outsource
3: partners

1: Hire.

If you need developers in an ongoing fashion, and you require complete control. Hire some. Either as staff (e.g., PAYE etc) or by doing fixed length contracts (contractors). You could even split the work up, and farm it out to individual freelancers in units as small as an hour or two.

Normally, alongside a developers you will need to also hire a designer, and sometime a project manager of some description.

2: Outsource

Outsourcing means having another business handle a business operation on behalf of your organisation. For example, many places outsource HR, or security.

One method for having custom software written is to go to a software development company, be the client and simply pay them.

You do give up control, but you are also buying yourself a degree of insurance again you own bad decisions. The outsourcing company, will probably have hired people (see option 1) which they are reselling as functional teams.

The normal method would be to go to an agency. Different agencies will take projects in different fashions. Many will ask for a Request For Proposal (RFP).

3: Partnering.

Sometime, you could build a ragtag team with developers who are being “lent” towards you aim. For example, if your organisation is group of charities and businesses perhaps those group members could give up a small amount of developer time.

Often, when partnering occurs, the management process remains within the organisation. (who will often hire a project manager, or a single lead developer).

So those are the three options I am aware of for business structure. Next, what about methodology?

Methodologies.

Methodology is about how the software is developed. There are 2 prevailing methodologies in the software development world:

1: Problem Upfront, Solution Upfront (Waterfall).
2: Problem Upfront, Solution on the Fly (Agile)

1: Waterfall.

Waterfall is the transitional software development practice. My experiences of it are more limited (i practiced waterfall development when I ran + Lion, I have never experienced it in a large project).

From my experiences, waterfall means that all the planning is done upfront. Both the definition of the problem and the definition of the solution.

With a waterfall project, a big spec is written (normally by someone non technical) which is bided on by agencies or given to an internal team to “build”. Its not uncommon for designs to be commissioned and completed before the development team have even been hired.

2: Agile.

Agile takes a number of forms and I am not an expert. I have 3 years of agile experience within the BBC, but that is all, so my viewpoint here is limited.

The basic principle of Agile (see disclaimer above ;)) is that you define the problems upfront (often with “User Stories”) and then tackle each small element of the story piece by piece. Building something in layers. Using the output of one story to influence the development of the next story etc etc.

In the agile world, there are different methods (scrum, kanban etc), but they all boil down to similar tenets. Such as, estimation, thin slices, and defining the solution to the problem as closely to the problem entering development as possible.

Scrum teams work in sprints, often of 2 weeks or so. At the end of every sprint the aim is for value to be delivered to the user. So for example, an early sprint’s goal may be “Have a user system with avatars and secure signup”. Within that sprint a series of users stories (e.g. problems) may be developed. For example, the stories in a sprint about a user system may include “As a user I would like to be able to sign up” “as a user I would like to be able to sign up” etc etc.

The planning of the detail of those tickets (the definition of the solution) is done before the sprint starts, but not too far ahead.

I have probably murdered the definition of agile enough for now, but I believe thats the core of it. If you know better, please leave me a comment :D

Putting it all together.

So those two decisions, the WHO and the HOW can be combined to give you development options. I have enumerated a few below:

Who: hire a team How: Agile
Who: oursourcing How: Waterfall
Who: Partnering How: Agile

And so on.

And finally…

With all that said, what are my thoughts? How should you build a software project.? I’m afraid the answer is I don’t know. So instead of trying to make something up, here are my experiences with the combinations I have experience off:

Who: outsourcing How: Waterfall

This is how + Lion operated. I worked with a client to develop a spec and help them define their solution, or they came to me with a project to be built. I managed the build, building some parts myself, and subcontracting other parts as required.

Who: inhouse How: Agile (Scrum)

When I was working in the BBC Radio & Music team, we built the first version of iPlayer radio. I worked on an agile team named eno, as a front-end developer.

This was my first introduction to agile and it was impressive. The team operated with a very good technical project manager (an ex dev) who helped to organise sprints and provide updates to the wider business. The TPM also arranged releases and did work keeping the ticket management board up to date.

Who: Partners How: Agile (Kanban)

When I was working in platform engineering, business as usual support was provided by a team called the eagles. The eagles was the combined support of a number of scrum teams, each team contributed one team member per sprint to join the eagles team which operated using the Kanban model.

For BAU work, where tickets come in, are of differing sizes, but generally are smaller tasks, kanban worked well. I fondly remember the thrill of delivering tickets every couple of days. It’s enjoyable to see some work release a mere hour or so after its completion (in a scrum teams, releases were normally made once per sprint).

However, for project work (getting a new software build of the ground) kanban was more complicated. My experiences of kanban in this environment are less positive. While in theory planning could itself be a ticket (e.g., a ticket called “plan the user system”) it was way to easy for tickets to end up being co-dependent. This could mean that while there were 40 or more tickets on the backlog at any one time. Only perhaps 3 could be worked on.

My opinion is that it is better to start projects with scrum, but maintain projects with kanban.

Wrapping up.

I hope this article it useful. It’s not exhaustiveI’m and I’m sure its wrong in many places, but hopefully it gives a feel for the options which are out there.

Published: 28 July 2014 | Categories: , Permalink

Comment

Your Comment