What Does Your Backlog Say About You?

If you review a backlog it will intentionally or not reveal a lot about a team, its priorities, its values and the future its heading towards.

An even more fascinating aspect to this window into a teams inner workings is that if you were to tell the team what you think it says about them they would more than likely disagree.

This ability to analyse teams isn't some sort of mystical unexplainable art, its the drawing of logical conclusions based on the work the team chooses to prioritise as well as the apparent goals and motivations behind having this work on the backlog in the first place.

What You Don't Value

If you asked a team do you place value on stability, security and sustainability you would very much expect to see a room full of nodding faces.

However the make-up of stories pulled into sprints can very often tell a different story.

Teams will often have a strategy around how to deal with tech debt or security issues and the need to balance this with continued feature development. When a team has these issues under control they are able to maintain this forward momentum in a sustainable way while users continue to make the most of whats on offer.

Teams whose backlogs demonstrate significant technical debt who then continue to prioritise new features are sending a message which while inconvenient is none the less true.

It sends a message that the team intends to move forward regardless of whether or not they are taking their users with them and regardless of whether or not the direction they are heading in is built on sustainable foundations.

It places little importance on issues currently being faced by users, while users are facing issues with functionality already deployed this should the be number priority of any team. Promising users jam tomorrow is very rarely an effective strategy.

Something Like

A backlog should not simply be a place to register ideas or represent a to-do list.

A backlog should be a list of well defined work items that have definite value either to your users or to you as a business. All of these work items should be ready to go should the team be in a position to start work, it shouldn't be necessary to filter the backlog to find these work ready items or spend a time demystifying what is required.

Obviously coming up with this list of work items is an iterative process, it isn't possible to instantly define and document requirements or the technical implementation that will fulfil them. But this process should take place outside of the backlog and must be disciplined enough to only migrate items to the backlog once they have progressed to the ready state.

A backlog full of half thoughts or reminders about functionality that may or may not be useful will struggle to keep your development team productive and also fails to demonstrate a clear strategy for the product being developed.

Requirements can change and items on a backlog aren't fixed in stone but this doesn't mean they can't always be descriptive of whats required at a moment in time and be ready for implementation.

Spaghetti Stories

User stories should ideally be independent of each other, this should enable a backlog to be fluid and allowing teams to quickly re-order work items depending upon prevailing priorities.

It maybe that stories are inter-related in terms of delivering an end-to-end feature to a user but the ability of the team to work on them shouldn't necessarily follow the same inter-connection.

This is not always easy to achieve and can have as much to do with the architecture of the code base being worked on as the teams ability to craft stories.

But disorganised teams or teams that lack a clear direction are likely to construct a backlog that becomes rigid, this can be seen in sprint planning activity when the team struggles to put together an effective sprint because of blockages on certain stories causing a ripple effect through the backlog limiting the amount of work that is ready to pull in.

This can also make it difficult to identify the next shippable version of the software, this isn't always necessarily when the next feature is ready but the point at which a group of changes can be made to the code that move it forward whilst allowing it to be stabilised.

A key skill for any agile team is the ability to map a path from story to story delivering software with value to users and the business along the way.

The backlog and the sprints it drives are the heartbeat of an effective team, it is more than just a collection of work items it should be a manifestation of the strategy the team is following and the direction it is heading in.

As much as it can reflect the success of a team it can also be indicative of its failings. Because of this teams should take the time to asses the health of its backlog and attempt to draw conclusions on what could be improved or to emphasise what is working well.

Treat your backlog as n indication of the agile health of your team, treat it with the respect that you afford your codebase and keep a keen eye out for signs that the quality of its stories are on the decline.

Agile Deployment

Deployment is the end goal of any software development activity. Whether it be to the desktop, a server or app stores, why write software if the ultimate aim isn't to deploy it so it can be consumed and used.

Methods and strategies for deployment are widely debated and although the technologies used are important the overriding factor governing success is the mindset that's adopted towards shipping the code.

If asked what deployment should be like in an agile environment many teams would use variations on the concept of continuous integration. But this concept can sometimes be quite intangible how do you actually know if your achieving continuous deployment?

Continuous is Different from Regular

An unfortunate consequence of us using the word continuous to describe an ideal deployment strategy is that it implies a regular cadence is the only thing we should be judged by.

A more descriptive phrase of what we should be aiming for would be unrestricted deployment.

While a regular cadence of deployment brings with it many benefits, no matter what the frequency maybe if any of your processes enforce that deployments can only be made at that cadence then this will still cause you and your team problems.

An effective deployment strategy enables you to release whenever you want or need to. It means the only factor in deciding whether or not to deploy is whether or not the code is ready.

An ultimately effective strategy stops this even being a decision that needs to be consciously made, your systems and processes deploy code whenever it reaches the state of being done.

Deploy Code Not Features

Not every change to a code base results in something that is visible to the user. The introduction of new features can take time to come to fruition and require many changes to the code base.

If we view value as only coming from completed features this can easily lead to big bang deployments that drop a large amount of change into production.

If we can derive value from the stepping stones in getting to a complete feature then we can break this single potentially disruptive deployment into many smaller safer changes.

These small deployments will, via a cumulative effect, still get us to the desired outcome but because the surface area of change was always kept to small increment our risk of breaking something will be greatly reduced.

The user may not see any visible difference until the final deployment that fully enables the feature but they also haven't seen errors or been frustrated by a large deployment that changed many things.

This approach of deploying code when its ready will also encourage us to architect our code to be formed of distinct, separate and well defined blocks, this has many benefits for our overall code quality as well as making our deployments less stressful.

Not Wrong for Long

Many aspects of software development can be an inexact science. This is not just down to the complexity of building software but also the unpredictable nature of trying to predict how users will interact with it.

The concept of failing fast in an agile environment acknowledges this and attempts to make it ok to try things even if they will sometimes fail to have the impact you'd hoped for because we learn by the experience.

It is also, no matter the level of testing employed, virtually impossible to deliver bug free software. While we may hope to reduce these inevitable defects to the smallest and least impacting sometimes one will slip through the net.

Both these aspects means rolling back or fixing production will always be something that a team has to face. If the team doesn't have faith or confidence in its deployment process, or has to wait to deploy in the next available slot, then stress levels will rise.

This can easily lead to a reluctance to try things or conduct worthwhile experiments around what users want or need.

All of the points that have been made here link back to the fact that deployment should be easy, repeatable and in no way onerous or stressful.

The long slow build up of stress towards release day should be put to bed in favour of an automated and flexible approach that puts code into production whenever it serves the purpose it was originally intended for and meets our definition of done.

Code it, ship it and move on.  

Bring Out Your Defects

Debugging is a universal pain known to all developers and software engineers, despite our best efforts to improve and get it right this time its an inevitable outcome given the complexity of writing code at scale.

It can have many stages from denial and anger to acceptance and ultimate resolution.

Given that, engaging in debugging is unavoidable and its clear that we need a strategy for effective debugging. For many this is built up from the scars and wounds of previous battles with a code base, it will also be influenced by the particular area of development that you operate.

What is presented here is far from a full proof strategy that will always enable you to root out defects quickly and painlessly, but any tips and tricks can be useful to have in your armoury when you go into battle.

Don't Panic

First and foremost don't beat yourself up when a bug is uncovered, writing bug free code is virtually impossible once your code base grows beyond a certain size. Developers and development teams should be judged on how they deal with defects not simply whether or not they exist.

The majority of defects will be simple mistakes, when a defect first appears we can often assume it has a complicated root cause. Instead, accept your human fallibility and expect to find out that you've just had a momentary failing of intelligence.

The first action should be to make sure that you understand the manifestation of the defect and you have a path to reproduce, without that not only will you struggle to find the cause you will also have little confidence that a potential fix is effective.

Once you start attempting to find a fix try to reduce the number of variables in play, change one thing at a time and have a heightened sense of when you've reached a point where your not sure of the logic of what your trying anymore. 

When it works you need to be able to explain why.

For a complex defect you will more than likely have several false starts, reset your approach whenever your in a situation where even if something works you won't be sure how your got there.

Use Your Tests

Unit tests are invaluable in proving your code works after you make a change, they also have equal value in demonstrating how your code isn't working.

Well written tests act as documentation for how things are supposed to work as well as providing an effective test harness to enable you to exercise the problematic piece of code.

When a defect has been identified, assuming you don't already have a failing test, construct a test that will expose the problem and use this as your primary means to attack the issue.

Not only will this help you analyse and ultimately fix the problem it will ensure that any potential future regression can be identified quickly and stopped.

The tests you add will also act as documentation for any developer who may touch that area of code in the future of the potential problems that can be introduced.

Write Debuggable Code

The majority of us tend to worry about optimisation far too early in the life of a code base, this early over optimisation can often come at the expense if readability and simplicity.

While there are always caveats to any sweeping statement in the majority of cases a lack of maintainability is likely to hurt your team much sooner than a lack of performance. Indeed one is likely to have a linkage to the other as successive developers make sub-optimal changes to a code base they don't understand.

Debuggable code exhibits a clear statement of intent along with a clear approach.

Overreaching for conciseness or performance can act to hide intricacies that will hamper efforts to debug and patch.

Comments are no savour for this situation, while they have a place they have no direct link to the code they are associated with and can easily cause more confusion than insight.

If you are unfortunate enough to have to apply a fix to code like this then consider refactoring to increase maintainability for the next developer to come along. Code that has previously had defects, especially ones that have been difficult to solve, is probably more likely to have them again and each subsequent patch is only likely to make the situation worse.

Being an effective debugger is one of the skills that comes with experience, the scars that can come from a debugging battle are a rite of passage for a developer. Whilst it can portray elements of an art over a science an acceptance of it being part of the development cycle and approaching it in an analytical manner can provide an effective framework for gaining that experience.   

Ideological Differences

Software development on the surface can sometimes appear to be a cold and methodical discipline. The scientific and engineering aspects it employs can make it appear that there are universal truths and problems with only one solution.

The number of times these things do exist are actually rare, problems generally have many solutions and most perceived truths have caveats.

What enables those of us that work in the industry to make sense of this and find a way forward is having an ideology, this helps us form opinions on what is right and wrong and provide our guidance on how to approach solving problems.

But sometimes ideologies can clash, its therefore important to understand why they exist and how they influence ours and others view of the working world.

Born From Available Skill Sets

The development of most pieces of software can be achieved using different technologies. Mobile has Native, Xamarin or Hybrid web technologies as an example and there are a plethora of technologies available for developing web based software.

With many of these approaches disciples will preach the benefits of one over the other, but its important to realise that its unusual to find people that have equal ability and experience in all available technologies.

This isn't to say that this discounts their opinions, there are advantages and disadvantages to all technologies but it is likely that people are seduced by a technology that means they can apply their existing skillset in new ways.

There is nothing wrong with this, being productive is obviously important for any developer. Instead embrace this in built bias and choose the technology that is right for you not that is right for other people.

Born From Metrics

Many different forms of tooling exists for measuring and analysing source, these tools can produce metrics to cover all sorts of aspects of the code we write.

Sometimes these metrics can be in conflict such that it isn't possible to optimise every measure, placing an emphasis on one will lead to degradation in another. The metrics we decide to measure ourselves by and use to define if our code is healthy is therefore driven by the qualities of code we feel are important.

This will lead to us developing an ideology that promotes the improvement of these metrics at the expense of others, if these are the metrics that you value then this maybe perceived to be producing bad code.

With a discipline as complicated as software development these conflicting views on good and bad are inevitable.

When analysing code its important to understand where the people who wrote it were coming from, armed with this knowledge you can properly asses if you have something to learn from their efforts to improve your own outlook.

To do this you must have an appreciation for all metrics and associated ideologies even if you may choose not to emphasise them. This will enable you to extract the core intent of code and give you the ability to continue to learn from others code whilst still potentially adapting it to match your chosen ideology.

Born Outside of Technology

Software development doesn't exist in a vacuum and neither do the people that create it. Many influences outside of purely technological concerns can shape peoples view on the world and therefore how they choose to write software.

This isn't a place for me to be judgmental about what these influences and views might be but realising that engineers are humans as complicated as the software they produce enables you to apply a filter to the ideology thats presented.

If you don't understand or agree with the arguments being made on technical grounds then maybe its because they are born from other influences.

This will be a common occurrence when operating in the world of open source software where the individuals involved may well feel strongly about the use of the software they are producing and the ideology it represents. 

As with the other sources of ideology that have been presented here the importance is in recognising they exist and using this knowledge to navigate through the potentially overwhelming volume of opinion and views they you will encounter.

Make sure that you don't dismiss potentially valuable insight and learning because you don't agree with the arguments or views in there entirety.

Also recognise that whether you like it or not you are also developing an ideology, this will be shaped by your skillset, experience and views on the world, both technical and non-technical.

Embrace this to ensure that you are able to express it to others and also recognise where it clashes with others to ensure you can get past this and not lose out on potential improvements you can make that you can agree on.

While it would be great to be in a world where all disputes and arguments are won or lost based purely on technical merit engineers are people to and they can't help but have biases and views that will influence their approach.

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.