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.

Nike Development

When you work in a development team, especially one of a reasonable size, you eventually end up spending a significant amount of time on planning and preparation.

This is necessary to ensure that the output of the team moves in the right general direction and nobody would suggest that chaos is more desirable alternative.

However there is such a thing as analysis paralysis and sometimes there are advantages to having an attitude of "just do it".

Learn By Doing

Software development is a cerebral activity that requires upfront thought, simply starting to bash out code will very likely result in a slightly incoherent code base with a lack of discernible architecture.

On the flip side any problem of significant complexity will prove difficult to get to grips with purely on the white board. No matter how carefully you try and map out a solution you will always discover problems in your thinking once coding starts.

This is a difficult balance to strike and relies on having a sense of when more thinking is required and when more diagrams won't help and the time has come to try something out.

This has to be coupled with an Agile mindset of expecting bumps along the road and being prepared to adapt and think on your feet when a wrinkle in your thinking is revealed. 

Software Over Documentation

A consequence of trying to move to the coding stage quicker will be that you will naturally accumulate software faster than documentation.

I do believe documentation is important and your thinking behind a system should be available for others to consume, it is simply a matter of detail.

The details of exactly how something works change and the code that implements that detail will always be the best documentation of it, ultimately its the single source of truth as its actually doing the work.

Documentation should provide enough insight to indicate intent to those that read it to guide future enhancements in the right direction.

It shouldn't delve down into the inner workings of the machine and it certainly shouldn't do that before the building of the machine is underway.     

Embrace Failure

The underlying narrative of this thinking is one that people sometimes find difficult to contemplate.

Not everything is going to work the first time you try it. Software development is way to complicated an activity for that to ever be the case.

If you accept that fact of inevitable failure then the choice is a stark one, would you rather fail after months on the drawing board or would you rather fail after a shorter amount of time with at least the possibility that some valuable software has been created even if some is also flawed.

There is also an implication that failure has to be managed, both with its impact on timescales and delivery, and also defining what is an acceptable level of failure in a design if we still want to ship it.

This last part is in essence the nature of an MVP, its acceptable for a design to be flawed in that it doesn't support all possible features or functionality. What isn't acceptable is that its flaws prevent those features from ever being implemented in the future.

The role of any software development team is to produce software that addresses a business need. 

That doesn't mean software should be produced at any cost, a lack of thought in what your doing will always catch you out in the end.

But no design will be perfect and no solution foolproof until they have been proven with working code that implements them.

The sooner you can move on to coding the quicker you will gain a warm feeling that this will work, or sooner you will receive the feedback that a new approach is required.

If you arrive at the stage that you think I need to try this out, just do it.  

The Pragmatic Architect

The role of a Software Architect is not a purely technical role within an organisation.

While you are tasked with ensuring technical competence you must also have an appreciation for the business goals of your organisation and understand what is required of you to help achieve them.

The majority of companies are not in the software production business, they are in the solution delivery business.

That means that being a Software Architect is a delicate balance between ensuring software is being built in the right way but also ensuring that it ships to customers so it can deliver value.

This requires a pragmatic outlook taking into account many different factors and influences and finding a way forward on all fronts.

Debt Accounting

Technical debt is incurred whenever a sub-optimal choice is made in the solution to a problem.

This is very different from implementing something badly, instead this can mean not dealing with all edge cases, not optimising performance or not implementing all possible variations of a feature that may be technically possible.

This amounts to trying to rationalise the scope of work and ensuring that something that is viable is achieved within opportune timescales.

Viable in this context means not only that it delivers tangible value to users but that the value is delivered via the application of viable engineering, meaning it is testable, scaleable and adaptable.

Whenever you chose to incur technical debt, and you will be faced with situations where you have to, ensure that you understand the nature of the debt, the limitations it will impose and how you will engineer it out of the product when the time comes.

No project is free of tech debt so having an effective strategy for dealing with it is an essential skill.

Maximising Opportunities

As an Architect your primary goal within your organisation is to engineer the solutions it requires, but achieving this by the application of solid engineering principles is no less important.

These dual responsibilities will often clash which is why you must always be on the look out for opportunities to advance both causes when they arrive.

Your organisation will primarily be concerned with the delivery of features, the details will be left in your hands, so learn to recognise an opportunity to deliver a solution and advance your underlying engineering platform at the same time.

Alternatively by having a close understanding of any previously incurred tech debt you may also be able to advance a solution that addresses these issues as well as delivering the required value.

In this sense you can save others in the organisation from themselves by giving them the solution they need rather than necessarily the one they are asking for.

Pragmatism in knowing which battles to fight would also come under this banner, knowing when the business imperative is too strong to try and turn the situation in an opportunity for refactoring or engineering. 

All in the Presentation

Architects often cross the divide in an organisation between the technical and the non-technical.

This often means developing two different forms of communication, you must be able to explain technical concepts to those being asked to implement them but conversely explain the same items in plain english to those being asked to fund or resource the development.

One set of people want to understand the detail and get to grips with the technicalities of what is being asked for and one does not.

When talking to non-technical people through an architecture the conversation has to focus on the benefits that will be realised by taking a particular approach, shaping the conversation like this enables people to make the correct decisions.

As proud as you may be of your solution, the details of your genius will not have the desired impact on your non-technical colleagues, it is much better to talk in terms of outcomes rather than the technicalities of getting there.

Being a valuable member of a team usually involves being well rounded enough to able to see problems and challenges from multiple perspectives.

As an architect being a zealot who only ever thinks about the technology will ultimately decrease your value to the team and reduce the effectiveness of your solutions.

In any aspect of life finding balance can be difficult but simply being open to the possibility that an organisation has goals beyond simply producing software is a good start.   

One to Rule Them All

Software engineers often display a strong preference for compartmentalisation, a place for everything and everything in its place.

With this in mind it might seem like heresy to suggest that all source code for an estate of products should be stored in a single code repository.

Naysayers will scoff at the notion but many organisations that maintain extremely large code bases, namely Google, Facebook and Microsoft, have moved to the concept of a monolithic repository with every line of code in a single place.

Have these development teams taken leave of their senses or could it be that the benefits of having one repository to rule them all are too good to ignore?

A Wonderful View

Having the ability to view a entire code base all at once can enable us to identify patterns across many different areas of code that may otherwise be difficult to spot.

Tools that produce such metrics as duplication, technical debt or even security issues gain a whole new power to deliver insight when they are scanning every line of code you have at once.

Having the whole code base in view will also empower developers to find more ways to share code, by performing even relatively simple searches through the IDE developers will be able to uncover where similar problems have already been solved to the one they are facing.

This increased capacity for collaboration coupled with a more inclusive attitude to code ownership can reduce the need to re-invent the wheel and ensure re-use becomes a default approach.

Atomic Refactoring

Its frequently the case that we are prevented from doing the right thing because of the potential pain in trying to manage the change across multiple code bases.

Once all the code is in a single place not only is it easier to envision the changes that need to happen but it can be implemented in a single atomic operation.

Even a simple yet wide reaching change such as re-naming a class or changing a namespace can be achieved across the entire estate in a single operation.

This can also prevent refactoring getting off to a false start where the true impact of a change isn't fully realised before implementation begins.

The freedom this gives a development team to contemplate refactoring that they would never normally be brave enough to attempt can liberate them to do the right thing on a much more regular basis.

Simplified Dependency

A potential headache in maintaining any code base relates to the management of dependencies.

This can be tough enough when dealing with dependencies on 3rd parties but when we create a large set of interconnected internal code bases we only increase the size of this potential nightmare.

By essentially building all our internal dependencies from source we reduce dependency hell to its smallest possible size.

The benefits of atomic refactoring and a complete view of the code base also make the job of updating a dependency easier and more palatable then may normally be the case.

Many reading this might be thinking isn't this desire for a monolith going against many of our ways of thinking for creating independent pieces of code such as SOA or micro-services.

This is where I feel we need to draw a distinction between how we organise our source code and how we deploy it output.

A single repository doesn't have to mean a vast single solution or project.

It is possible to realise all the benefits described in this post whilst still on a day to day basis working on a small and specialised area of the code base.

The fact that it is possible to load the entire code base doesn't mean that has to be the normal course of operation, but the fact we can if we choose to see our entire world at once gives us the ability to more effectively shape it.

It would be wrong to suggest that moving to a single repository is pain free, it does place extra stress on tooling and all the companies mentioned that have adopted the approach have had to adapt their ways of working, but the potential benefits it can bring are difficult to ignore.

How to Break Agile

When any school of thought, way of thinking or approach to a problem becomes significantly popular and widely adopted then a counter culture starts to grow to oppose it.

Often it is to the benefit of all of us that perceived wisdom is challenged, however I believe most of the criticism of Agile is actually misdirected, in that it actually relates to flawed implementations of its principles rather then making a killer blow against the entire philosophy.

Agile is not a procedural approach to development it is a way of thinking, a mindset to use to maximise the output of a team.

When Agile is seen to not be working it is usually because of a failure to adopt this mindset.

Fix Time and Scope

When trying to manage a software delivery there are two levers that can be pulled to adjust the outcome, we can make changes to the scope of the release or we can change the date on which software will be delivered.

Changes in scope can either increase or decrease the effort required to complete the delivery, and changes in deadline can either increase or decrease the amount of available effort we can spend prior to releasing.

What we have to realise is a relationship exists between those two things, the fact being that they cannot both be fixed at the same time.

To do so either leads to inefficiency that delays the release of working software or tries to arrange a situation where software is delivered without effort being expended.

Deadlines are a fact of life and it would be foolish to imagine a situation where they don't exist, but as soon as a date is fixed then scope is the only lever left to adjust the teams trajectory towards hitting that target, if that isn't an option then the difficult decision of moving a deadline must be faced.

Failure to Iterate

Although not expressly mentioned, an Agile mindset leads to a certain acceptance that software development is an unsolvable problem.

Your product will never be finished and it will never be perfected.

Once we've learnt that lesson then we can gradually come to the realisation that the next best thing is to try and ship frequent incremental updates to ensure the product is the best it can be right now.

The delivery of this incremental change may be imperceptible to users but allows for a direction of travel to be established.

When the apparent big bang of a new feature is discovered by a user this is actually just one more small delivery, providing the cherry on the cake of several previous unseen steps forward. 

A failure to iterate is often the result of a failure to properly prioritise.

A priority is a singular entity that stands alone, to pluralise prioritises is to admit to a lack of vision for the direction the product should move in, it leads a strategy akin to throwing around features and seeing what sticks.

Speed becomes of the essence as we increasingly fear that users will leave us without the next big thing, when actually users are often happy to have something that works that receives regular attention to ensure that remains the case.  

Breakdown of Trust

Many would find it quite shocking to be asked if they trust their development teams.

But actually it is not uncommon to observe behaviours that indicate that trust has broken down.

First and foremost this is seen during the estimation process, too often there is seen to be a right and wrong answer to providing an estimate.

Development teams shouldn't be asked to estimate as a courtesy, it is because they are experts in there field. 

Repeating estimation without any conversation around scope leads to the madness of asking the same question over and over until the calculation yields a different result.

Trust can also be eroded when a development teams warnings about potential bumps in the road are not heeded.

Too often this is seen as engineers obsessing about technical detail, while on occasion this may be true, this comes from people who understand all the moving parts of the code base and therefore can also envision the areas where the machine may start creaking.

There is more to being Agile then simply adopting its ceremonies and ticking the boxes of its various implementations.

Agile is a philosophical viewpoint on how the unenviable task of software delivery can be approached.

It isn't a formula that can be solved to produce a proof for success.

Many teams start off with good intentions and want to do the right thing but they eventually encounter the pitfalls of allowing their minds to drift to more attractive ways of viewing the problem that promise a solution that will never be delivered.

Learn to recognise the signs of these mindsets creeping in to your team and use these opportunities to re-affirm your commitment to keeping an Agile mindset.

This will inevitably lead to giving up some perceived control over a situation, the first step towards a transition to Agile from more traditional methods is to realise this control is an illusion, the world simply isn't like that.           

Always Deploying

Within most development teams we're becoming used to most things being continuous.

The adoption of Continuous Integration (CI) has given us tooling that can ensure the effort of developers can be combined at the earliest opportunity, and an increasing emphasis on shifting left has made it possible for us to ensure quality is a default position.

But ultimately software has to be deployed to be of any value and despite all the tooling available to smooth this transition into production for many teams this final push is still something thats feared.

If your fearful of deploying code this will become a self fulfilling prophecy and things will go wrong, your fear will grow and you will deploy on an even more infrequent basis.

Break this cycle of fear and move to a situation where deploying to production requires little effort and is something that is a natural consequence of your team delivering.

Not Wrong for Long

The likelihood of an issue occurring after a deployment is proportional to the amount of change being deployed.

If you deploy large change infrequently not only do you need to be confident in your testing regime but its likely that if you do face difficulties you'll find it harder to roll back your changes to your last known good state.

If you deploy small change frequently the chances of an issue arising are reduced but also the fast route into production you've developed means rolling back is simply another deployment accomplished quickly and with little fuss.

This ensures that if the worst happens your not wrong for long.

A long drawn out deployment process is an attempt to make sure nothing ever breaks in production. While that's an admiral intention mistakes will happen and ultimately all this achieves is complicating the recovery from these unavoidable mishaps.

Continuous MVP

A misunderstanding of the concept of a Minimum Viable Product (MVP) is probably the biggest barrier to teams becoming truly Agile in their approach.

Infrequent deployments can exacerbate the tendency to try and squeeze more scope into each release because of the limited opportunities to deliver features.

When features can be deployed at will it becomes much easier to move people to a mindset of shipping a true MVP, they know the next release can be whenever some value has been added to the journey rather than the next scheduled window of opportunity. 

Reducing the time between an idea and a deployment into production also increases the opportunity for user feedback to have a real influence on the direction of a product. 

Feedback is received early meaning large amounts of effort isn't wasted on functionality that users don't find valuable, and once again if need be removing the functionality entirely is just another deployment. 

Don't Break It

Regular deployment of code will also encourage people not to break things.

Large gaps between deployments tends to encourage an acceptance towards parts of the code base being broken, inevitably leading to an increasing feeling of panic when release day does eventually bear down upon us.

When code is to be shipped as soon as its finished not only does code have to be maintained in a working state but this continual green light has to demonstrable, this leads to an increasing effort being put into effective automated testing and good documentation of what the code base working actually means.

Here a distinction can be drawn between Delivery and Deployment, even when operating a Continual Deployment strategy it isn't necessarily the case that every build has to be pushed to production, but it certainly should be the case that it could.

Aside from wanting to deploy new features at the earliest opportunity we can also never predict when an emergency, such as security vulnerability, forces into a deployment we weren't planning on.

In this situations it is definitely advantageous to know everything still works.

Continuous could be described as the mantra for modern development practices, all the activities we value should be happening all the time.

As the last step in the chain that connects us to our users this should also apply to deployment.

As with so many things its good advice to confront your fears, if release day currently comes with feelings of dread then give yourself the impetus to confront these fears and find a solution by having more and more release days.

Delivering into production should never be taken lightly, and quality should always be maintained, but its possible to do this while also trying to give users the value the instant its achieved by your development team.         

Engineering SLAs

As a developer you'll often be asked to explain why you have written certain pieces of code the way you have and some of this feedback may be critical in nature.

When your faced with this situation please don't use the justification "but it works".

There is so much more to software engineering then simply writing working code, if working is the only quality of code worth mentioning then I would wager it won't stay working for very long.

In order to qualify as an engineering discipline we should be aiming our sights a little higher and look for our code, and the systems we use to produce it, to have many more qualities then simply working.

Ability to Deploy Change

Software engineering probably exhibits the fastest rate of change of any engineering discipline.

A code base under active development by a large team may see thousands of changes being made to code daily.  For this reason the ability to accept change is an important property for a code base to have.

This may sound strange, surely any piece of code can be changed? Actually the ability for a code base to be changed, and not re-written, is something that can only be achieved via careful thought.

Many of the solid design principles, such as Single Responsibility, Open Closed and Dependency Inversion exist to promote this acceptance of change without having to throw away large portions of code whenever a new feature is requested.

But the ability to change or modify code is only part of the story, change that isn't deployed is largely a wasted effort, a code base must also demonstrate an ability to deployed easily and without fuss.

This is achieved architecturally via the use of patterns like micro-services but it also requires the confidence given by having well structured automated tests that can be relied upon to identify issues and potential defects.     

Ability to Determine Performance

We deploy code with a purpose in mind and our users expect it to perform that purpose with an acceptable level of performance.

Hearsay and rumour and not effective ways to measure performance, cold hearted metrics that can demonstrate what the code is doing and how well it is doing it must be thought about before deployment and continually measured and reported on.

This should create a feedback loop that when coupled with an effective ability to deploy change will accelerate your product to new heights.

Before the operation of software can be effectively measured it must be clear to everyone what each area of the code base does and how it does it. It must also be clear the reason certain events are generated and there importance to the overall success of the code that achieving its desired outcome. 

Ability to Demonstrate Security

If any single quality of code has been elevated in importance in recent years it is that it should be secure.

Any code deployed almost anywhere can expect to be the subject of inspection and attack, whether the intentions of the attackers are mischievous or criminal it is no longer acceptable for security to not be on the minds of developers at all times.

But security doesn't exist on paper or whiteboards, it exists when a system can demonstrate an ability to detect, repel and recover from an attack.

The ultimate manifestation of a code base that doesn't meet this criteria is one that relies on "Security through Obscurity", there are a lot of smart people out there trying to attack the code they find and you may find your secretes don't stay obscure for long once they turn their attention to your code.

Security must be demonstrated by a willingness to submit your code to deliberate attack.

There must also be an acceptance that sometimes security flaws will be uncovered that must be fixed, sometime they will be found by effective monitoring and once again when coupled with effective deployment of change this can ensure windows of opportunity for attackers are as small as possible and closed as soon as they are found.

The minimum that should be expected from any developer is code that fulfils its original purpose and can be said to be working.

Those that rise to the upper echelons of their profession don't stop when this minimum acceptable state is achieved, they instead realise that code must also demonstrate some other important properties.

In this way they elevate their art beyond the mere production of working code to an engineering discipline with all the rigour and attention to detail that is implied.