Road to Ruin

Within the technology sector we regularly refer to businesses as start-ups. Its not always clear what qualifies a business to be included in this category but increasingly we think of them as the nirvana state for an organisation to be in.

We are often asked to think the way they think or approach a project in the way they would. To let go of our ingrained reluctance and to embrace a more can do attitude.

But does this not give rise to a paradox? If start-ups are the optimal state to be in then why do so many fail?

The Problem Business

Many start-ups are born out of a passion for a particular form of technology. Providing expertise in the application of that technology can provide a path to success, but its important to understand that the basis for a start-up should be the definition of a shared problem.

Successful start-ups define a problem that needs a solution, they don't create a solution and then attempt to find the problem it solves.

If the technology you provide is a well formed and reasoned answer to a well understood and common problem then the need for you to sell and persuade is greatly reduced.

Potential customers will recognise for themselves how you can help solve their problems, they won't need to be seduced to recognise the value of what you are offering.

Growing a start-up shouldn't have parallels with Jeopardy, because it runs the risk that you have engineered the answer to a question no-one was asking.

Baby Steps

A perceived virtue of a start-up mindset is to exist firmly in the hear and now, to not waste energy on what-ifs or potential future issues until they exist.

Its true that a healthy agile mindset promotes a realistic attitude towards not over thinking future requirements. Crystal balls are an unreliable technology and shouldn't be over used or unduly trusted.

While all of this is true too many start-ups do not anticipate the expansion that will be required as success grows. This is a difficult balancing act to follow, spend too long building for scale that never comes and you may miss a market opportunity in the here and now.

Another advantage of an agile approach is to try and break down large problems into small problems, and this should be the approach when looking at scale. If you currently have ten users then there is no need to start thinking about having tens of thousands, but you probably should start thinking about having hundreds.

You should have a plan for the next milestone on the horizon and not be caught out by the success of the thing you've worked so hard on.

Paying Dues

This will probably sound like an absurd thing to say but a failing for a lot of start-ups is trying to be profitable.

To qualify that statement, I am not advocating that start-ups should waste money or not be focused on having a plan to monetise the solutions they are offering.

But those should be longer term aims, in the short term start-ups should have courage and faith in the mantra they are preaching to potential customers.

In an attempt to recoup income during those early infant steps start-ups can sometimes come across as amateurish or lacking in conviction.

Nothing will do more to inspire confidence then forgoing income until your customer has realised some value from what you are offering, tie your success to theirs.

This absolutely has to be part of a longer term strategy to properly benefit from initial outlay and an equal number of start-ups fail precisely because they don't have a plan to make money.

This is about realising that a plan for success in a complicated industry has to be nuanced and be made up of many different stages.

There are many benefits to start-up culture and having that hopeful can do attitude that people associate with it. But it isn't a blueprint for success in and of itself, the reality of operating in a complex and competitive industry means that no particular philosophy can be guaranteed to bring riches.

Find a problem lacking an effective solution, take a pragmatic approach to its implementation and keep yours finger crossed.

Winning the Game

As much as I would like to argue the opposite software in and of its self has no inherent value. Simply accruing more and more of it will not necessarily correlate to success, it is a raw material not a precious commodity.

The game is to develop ways to use that raw material to build experiences that create a value exchange between your users and your organisation. This is not as easy or obvious as some may like to believe, just because you build it doesn't mean people will want to use it.

If anyone, myself included, could provide tactics that would be guaranteed to win this game than we would be wealthy individuals.

What I'm going to present here are simply my views on ways of thinking that I believe increase your chances of winning.

Failure Isn't an Option

Creativity and innovation are important aspects to software development but they can also tend to initially lead to instability.

This doesn't mean we shun or avoid them but we do need to place them in a hierarchy of objectives, the undisputed king of this hierarchy is reliability.

In many aspects of their lives users aren't as quick to reach boredom as we may think. Even if the value you deliver to them is relatively simple in nature if you deliver it in a timely manner with unwavering consistency users will continue to use it.

There is such a thing as competition in any market place, if your attitude is too conservative then eventually you will be overtaken, but having a reputation for consistency and reliability should not be willing exchanged for one of allure coupled with unpredictability.

Define some metrics to describe your reliability and performance and ensure that effort is always spent to improve these metrics and that no feature is considered that would adversely affect these measures.

Backend Driving

Because users interact with the front end of your system its deceptively easy to become overly focused on the tip of the iceberg.

Users will always exhibit magpie tendencies and be drawn towards an attractive and slick experience. But the hold this has over them will quickly dissolve if this beautiful front end is frequently informing them of failure or is a vale trying to hide a lack of functionality.

I'm not suggesting that we should all go back to the days of basic HTML or that we shouldn't try and construct compelling experiences.

The point I'm making is that the front end of an application should be a window into a well functioning, feature rich backend that is able to deliver the functionality and features that users need.

A significant issue for many new systems is that they have an overly high preoccupation with the development of the front end at the expense of laying the foundations for a scaleable and performant backend.

This leads to a lack of useable functionality that is eventually exposed despite the appealing way in which it is being presented.

Paying Attention

So far we have made a lot of assumptions that we know when we are delivering value and can detect when we are failing, but we shouldn't assume that its a given we can properly measure these things.

The currency of success in a digital marketplace is data, the more you have, from as many diverse sources as possible the greater your ability to know more about the world then your competitors.

Any and every opportunity to record and amass should be utilised. The primary focus should be on the collection of data, measurement and the production of metrics is a secondary activity.

Whenever we decide to measure or analyse data we inadvertently make assumptions that cause us to ignore or dismiss data based on our current understanding of the problem we are tying to solve.

This bias is unavoidable but should be introduced at the last possible moment not at the point of data collection, in broad terms there is no such thing as good or bad data but rather valuable or flawed interpretation.

Your ability to accurately interpret data may change over time but this shouldn't mean you permanently discard items whose value won't be appreciated for some time to come.

This should also include the dropping of an assumption that we are supposed to be proving we are right. To do this assumes we won't or can't find areas to improve, that our systems don't fail or couldn't perform better.

Enough business fail to bring home the reality that we get things wrong a lot of the time.

Being successful is an inexact science, you can do a lot of things right and still lose. But its important to realise its a long game, short term gains won't always add up to produce long term success.

Always be thinking about the long term and don't easily give up hard earned stability, scaleability and technical competency.    

Are You DevOps?

Software engineering even as a relatively young discipline can still point to a plethora of different approaches to its implementation.

Many come and go but some gain traction until they become standard perceived wisdom.

One practice that is moving towards achieving that status is DevOps.

Many others have listed the values that DevOps holds dear alongside the techniques used to achieve them, but how do you know when you can truly say you have achieved a DevOps culture?

When You Postpone a Release

A core tenant of DevOps is to increase the speed and frequency of delivery, a failure to achieve these things is a principle reason that holds people back from both a DevOps culture and being truly agile.

However once you are comfortable with a DevOps approach then you will have reduced a release into production to be business as usual, simply a consequence of your teams completing work.

This nirvana means you will no longer be tied to a rigid left to right series of releases and will be much more confident to release when code is ready.

You are achieving DevOps when you can postpone a release without causing stress or discomfort to your teams or stakeholders. If something isn't ready today maybe it will be ready tomorrow or the day after, whenever it is ready we'll ship it.

When Development Teams Make an Infrastructure Change

A DevOps mindset tends to acknowledge that we have developed pretty effective ways to manage source code, so why don't we try and extend that philosophy to other areas of engineering.

All software requires infrastructure to be deployed to and run on. The definition, maintenance and management of this infrastructure has very often been a sticking point for teams that requires engagement and therefore dependency on others in the organisation.

A DevOps mentality combined with the ever increasing toolbox provided by cloud computing have given rise to a situation where we can define our infrastructure using tools that stand very close comparison to source code.

Not only does this mean it can be managed using similar tools but also that it can accept the rate of change and modification that we would normally only expect to see from traditional programming.

When You Fix a Bug Found by Automated Testing

A DevOps approach employs near continual testing of the system being developed.

These tests may operate at different levels, from unit tests to integration tests to automated UI tests. All these tests suites are automated and can be triggered from any event in the build system.

This can provide a dramatic increase in the amount of testing a code base is subjected to making it possible to simulate much more usage of the system than is possible via more traditional methods.

These increased levels of usage will result in bugs being exposed during development that would normally only be seen during production volumes.

We shouldn't expect to never see bugs in production again, but any tool that can increase the number of potentially user impacting bugs that are fixed prior to release has to be of value to any development team.

It is usually not possible to say that any approach to software development has truly been achieved. Most, including DevOps, have more to do with instilling a certain frame of mind within a team to influence decisions that are made as part of delivery.

In this sense no team can be said to have achieved DevOps, they may simply be more experienced in the application of the philosophy, they have moved past some of the more obvious pit falls and are reaping some of the benefits.

The intangible nature of achieving DevOps makes it even more important that we recognise the practices and behaviours that indicate that we're heading in the right direction.

The journey may never end but there are sign posts along way.

Which Teams Work?

Although writing software can be an introspective and individual pursuit in a commercial setting its generally developed by teams of people.

Different functions exist within the team all of which hopefully come together to form an effective code delivery unit.

In large organisations multiple teams will be born in an effort to further expand an engineering capability. This growth will usually involve decisions being made around the make up of teams and the division of responsibility.

What category of teams are available to choose from and what are the relative merits of each?

I think this very much depends on maturity, both as an organisation and of the product you are building.

Platform Teams

A platform team is focussed on delivering one entire tranche of an overall system. This may represent a channel by which you are in contact with your users, for example having a team focused on mobile development or one focused on a retail website.

This may also represent an essential sub-system, one that may not be directly visible to users but is essential to the success of your organisation, such as your customer database or you billing platform.

When your organisation, and its software base, is young and underdeveloped this concentration on building fundamental building blocks can be essential to developing something beyond vaporware and ensuring a focus on the definition of a robust and scalable architecture.

Developing in vertical slices may have its benefits in terms of delivering fully fledged solutions to customers, but some thought must also be given to scaling horizontally and joining up the components being built.

Feature Teams

When your organisation becomes more mature and you have a base of software that delivers the functions you need to deliver value then the platform model can becoming limiting.

It can create a bottleneck of dependency on certain critical components and act as a handbrake on teams that need to source functionality from these important sub-systems.

Feature teams look to break this dependency by creating cross-skilled teams that are comprised of expertise in many different areas that are brought together to achieve the delivery of a feature to end users.

In crude terms it brings experts in the necessary front end and back end technologies together to work under a single team umbrella, rather than requesting work from each other they complete stories together collaboratively.

Using feature teams can indicate a shift inside an organisation from constructing building blocks to trying to do something productive with them. But it can also put strain on maintaining a consistent architecture and is particularly resource heavy when multiple teams require a particular expertise.

Consultancy Model

I think there can be a third option to try and draw the benefits of both approaches whilst trying to limit some of the drawbacks.

I will refer to this as the consultancy model.

In this model a core platform team is responsible for providing continued development of a platform, they have an emphasis on progressing architectural concerns and ensuring the overall quality of the code base.

Aligned to this team are a group of consultants, they have an equal understanding of the platform as the core team and are equally invested in the same technical goals.

It is these consultants that are aligned to feature teams and work within them to ensure the platform they are an expert in can be utilised to deliver a feature, potentially making changes to it to facilitate this happening.

This consultancy model acknowledges that the collaborative agile nature of feature teams is a captivating proposition that can yield a lot of benefits.

It also acknowledges that someone must be thinking about the architecture and technical development of a platform, constantly modifying something to suit a particular need or developing in isolation and hoping for an architecture to emerge are potentially both recipes for a mess.

It probably doesn't solve the resourcing issue that can become prominent in a feature team model but at some point a realisation must be reached that there is only a certain pace of software development that it is practical to maintain.

It is possible under this model to move development resource around based on what is currently perceived as the most pressing need, either to facilitate feature development or to mature the platform and concentrate on sustainability.

As with many things you'll need to find your own way and discover what works for you and your organisation, the only important thing is to realise its something worthy of your effort to think about and plan for.