Agile Architecture

In many agile teams the role of architecture is derided and on occasion actively avoided.

I think this view point comes from mistakenly equating architecture with planning.

As agile teams we don't won't to get bogged down in planning and we don't require a large upfront design to get started in delivering value.

And thats fine because this isn't the role of architecture.

Architecture isn't about exactly how we might implement a possible new feature six months down the line, it should be about how we make sure our code base is built to accept change and adapt so that if that feature does come further down the line we haven't painted ourselves into a corner.

Agile teams will often describe their architecture as emergent, I think this can be dangerous if you expect a robust architecture to just come riding into view when you've paid it no thought, instead I believe we should be aiming for an emergent codebase that can go anywhere we want to take it.

Two Big Questions

I don't believe its anti-agile to take a small amount of time just thinking through the structure of the code were about to write, this thinking should be aiming to answer two questions,

How will we test this?

How would we change this?

Agile architecture should be about being able to scale, we need to be able to adapt to new requirements quickly and we need to be able to verify our code still works.

This means the two most important properties our code can have is testability and adaptability, being able to fall back on these two things means you will never be fearful of a new requirement. 

Failing to think about these two things means the architecture that emerges will be brittle and ultimately will fall apart.

Look After the Small Things

Although having this scaleability in our code base is a long term aim fortunately we can ensure we get there by taking care of the small things in the here and now.

SOLID is all about taking care of testability and adaptability, ensuring you write your code being guided by these principles whilst taking a small amount of time to think through how you want to structure things will allow for the emergence that were seeking.

Always Ready to Go

Once we have the emergent code base that will allow us to grow another important aspect of our architecture needs to be the ability to deliver at a moments notice.

For this to be a reality we need to embrace automation, in building, in testing, and deploying, the architecture of our build processes is just as important as the architecture of our code.

If we prefer working software over documentation then we need to ensure that as little energy as possible is expended in getting that working software though the door.

Shaping the Future

Software provides solutions to problems, the genesis for wanting to reduce the role of architecture within an agile team comes from our propensity to solve problems that don't exist yet or becoming too obsessed with minor details.

The role of architecture should be to create a framework to allow creativity, to enable solutions to be found and implemented when the need arises.

Good architecture stops us creating a straight jacket that suffocates us from being able to move forward.

Without this flexibility it is impossible to be agile, without a bias towards automation it is impossible to be agile.

The concept of MVP should be applied as much to architecture as it is to the product the architecture needs to deliver.

We need to define the simplest architecture that can possibly work and continue to work in the future when we change exactly what working means.   

Test Driven Benefits

I've written many times about the virtues of unit testing, first and foremost because its the best way to prove that code works as expected.

But as with many aspects of good development practices if you do the right thing you'll profit from many additional benefits.

This is also true with unit testing, its the right thing to do, and as well as verifying your code is fit for purpose it can be the mechanism for other good things to happen.

Consumers First

Code is written to be consumed by others, and the very first consumer is your unit tests. Its your chance to both document how your API is intended to be used as well as place yourself in the position of being a user of your code rather than the producer.

Unit tests can be used a design tool, as your writing your tests always be assessing does this make sense, pay attention to things like how much set-up and tear down is needed, does this represent state that will not be obvious to someone trying to utilise this class?

Unit tests are very good documentation, they not only demonstrate the code being used they also state expectations on the data that should be fed in and the data that will be fed out. 

Shrinking the Circle

Every developer has been on the treadmill of making a change to some code, deploying that code, interacting with that application, finding that bug is still their and back round to the start.

This is dull and inefficient, it might be several minutes before any modification can be verified and on a tricky pest of a defect might be a cycle that is repeated all day.

Unit tests are a very good debug tool, a bug in a class that manifests itself in your application should also be visible in your unit tests, if its not you need to write more tests.

Using your unit tests to find a problem will give you much quicker feedback on the impact your changes are making, if the tests are well written it also helps isolate the code that may be causing the issue, your able to ask more precise questions, does this class do the right thing in this situation?  

The What-Ifs

The infrastructure in your unit tests that ensures your mocking dependencies and decoupling your classes reveals your architecture, whether good or bad.

There is a lot of knowledge to be gained by looking at what tests break if you make a change, if we make this change a lot of tests in many different areas of the code base break, why is that and does that indicate we need to make a change?

It also allows you to speak with confidence if your asked a what-if question, we're thinking of adding this feature or making this change, the scale of that work will often be linked to level of decimation it will cause in your unit tests.

Following principles like single responsibility and open-close should ensure that changes don't cause carnage in your unit tests, you'll always be adding more unit tests but are you constantly having to re-write the ones you already have?

Hopefully everyone is realising the benefits of automated testing, and if the only benefit your drawing from it is the automatic verification that your code still works then its been worth it but be open to the fact that there is a long list of other benefits to be plundered.

This is just one example that if you do the right things good code will happen and you'll expunge less energy and brain power in producing it. 

Just A Pile of Bricks

While agile has taught us the lesson that spending large amounts of time on big up-front architecture is not necessarily productive this shouldn't discount the need for our code to have a recognisable architecture.

Architecture is what separates code from software, what separates development from engineering, and ultimately what enables continual improvement and scaleability.

So we have a fine balance to make between inefficiency caused by spending too long thinking and not doing and rushing in and making a mess.

So with this in mind how do we recognise when our code lacks an architecture? How do we know when we have a pile of bricks and not a house?

Avoidance of Thingies

The first step towards understanding what a class does should be its name, when a class is well-named looking through the source for that class should re-affirm what you assumed were going to see not shock.

The name should also imply that classes role within the overall architecture, allow certain assumptions to be made on how it is used and infer a commonality with other classes with similar names.

In code bases lacking an architecture this often isn't the case, in these code bases we have classes that share a suffix like Manager, Controller and Service that have very little in common.

Their public API's don't look the same and learning how to utilise one of them is a learning experience every time.

In a similar manner when you have to look under the hood you don't see much in common between them.

If were going to create well defined layers in our code classes that identify themselves as being part of that layer need to have commonality in approach and interface otherwise we end up with classes that may as well be called thingies.

Without this commonality we will end up with each class operating at different levels of abstraction and this imprecision will be passed out to all the classes that utilise them.

As a code base grows our understanding of how it fits together should grow not diminish, this is a Service I've used one of those before so I know what to expect, or I assume there is some kind of controller to deal with that.    

I'd Need to Look into That

A good architecture creates a narrative, you don't need to know the details of all the implementation to have an appreciation of how the system works.

This means when your asked questions like "would we able to do this?" or "what would be involved in adding this?" your able to understand and evaluate the work required and give feedback. That is not to say adding the feature is quick or easy but you understand what would need to be done.

When your working with a code base that doesn't have a clear architecture questions like this are difficult to answer and usually provoke the answer "I'd need to look at the code".

No assumptions can be made and every trawl through the source is an adventure leading to new discoveries about how things work.

When work starts on a new feature there often isn't any obvious starting point, theirs no pattern to follow or structure to fit into, everything requires an upfront brain storming session to figure stuff out.

Instead we want to be in the situation where most of the time (you can never account for everything) when were asked for something new we could list the classes or modifications that would be required because we know how things are structured even if we don't know the detail. 

Mud Pie Not A Cake

A by-product of having a clear architecture is the possibility of re-use, either within the same product or when starting a new product.

We can draw vertical lines through the code base and "lift and shift" features to slot into a different code base.

Looking at our code base is like looking at layers of a cake, clearly separated layers each with there own role to play.

When a clear architecture isn't present our cake becomes more of a mud pie, the structure isn't clear and each layer of code flows and bleeds into the other.

The possibility of re-use is greatly reduced, we can't cut vertical slices through our code because code keeps flowing through our fingers.

Ultimately an architecture needs to be flexible both to allow the code base to grow organically but also to bring the benefits of loose coupling for testability and re-use.

But even with this flexibility an architecture does need to be present and it does need to provide structure and bring all the benefits we've talked about.

This isn't an easy feet to accomplish and we'll very often get it wrong, thats why we need to recognise when an architecture is missing or is breaking down. Its easier to reverse a car than a ship, recognise when something is wrong and change it.  

What Does Anti-Agile Mean?

The majority, if not all, of the people reading this will be working in agile teams. That will mean different things in different organisations but that isn't necessarily a problem.

Agile isn't one size fits all, a drastic over simplification of agile might be "try things, do what works".

But when does something become anti-agile? When does it actually stop us from achieving our goals?

Interrupting the Flow

An important aspect of agile is effective and on-going communication, with the most valuable form of which being face to face.

Something is anti-agile if it gets in the way of people just talking and figuring stuff out.

This can come in many forms, poor division of work and resources causing constant blockages by being reliant on others who are siloed with there own problems.

By having a needless hierarchy creating ineffective lines of communication where the people who can work through problems are communicating via proxies.

An agile mentality assumes that if smart people are given the time and room to work with each other they will produce results, this process cannot be forced or controlled it just requires trust.

Build Something

Some other processes place a large importance on having a plan, its a misconception of agile that it doesn't involve a plan.

Agile does involve a plan, the difference is the scope, we don't plan to take over the world we just plan to make a start towards doing it. We realise that users can't use plans but they can use the things we build.

Anything that gets in the way of building something is anti-agile. This is nearly always caused by a fear of the unknown, how do we know this is the right answer?

The truth we have to swallow is your never going to know in advance that your doing the right thing, you cannot plan to succeed you can only plan to have your best stab at it.

Users tell you if you doing the right thing and they do that based on the product you put into their hands not based on the plan of what you intend to one day give them.

Listen Don't Tell

In a similar vain your best chance of succeeding is when you listen to what people want.

Users will tell you what they want, users aren't always right and sometimes you will need to persuade them that your idea is a good one but you won't be able to do that effectively and you want be able to adapt if you don't understand where your users are coming from.

Developers will tell you how they can best work effectively, they are the ones who have to make your vision a reality, if you don't trust them to know how to do that you've put together the wrong team, you need to succeed because of your team not in spite of them.

Its anti-agile to assume you have all the answers, an agile team will embrace their ignorance and see it as an opportunity to learn, to find out what people want and deliver it.

Flex Don't Snap

The theme running through these points is the need to be flexible, with agile the clue is in the name.

Questions can be hard to define, answers can be wrong, people can make mistakes. You can either spend a long time following a clearly defined plan moving slowly towards failure or you can accept the fact that there will be rough seas that require changes in direction.

Something is anti-agile if it prevents you from implementing change when you know its the right thing to do.

It sounds crazy to think that a team could know they are doing the wrong thing but carry on anyway, but it happens all the time when that team is operating in an environment that isn't agile.

Either the people that know this is wrong aren't communicating, your not finding out from the user if they want what your doing or your machine is so big that it simply cannot change direction.

You can't be told how your team can work in an agile manner, you have to figure that out for yourself, but there are guidelines you can follow.

You'll find your own way you just need to be able to recognise when your heading in an anti-agile direction and hit reverse. 

Playing Strong and Loose

There are four important concepts in development, sometimes they get mixed up but its important to have a good understanding of the relationship between them.

"Abstraction leads to loose coupling"

"Encapsulation leads to strong cohesion"

So why exactly are these statements so important are why do we sometimes get them confused?

Abstracting Away the Detail

The purpose of abstraction is to hide detail.

Detail leads to complexity, complexity leads to instability and instability leads to unhappy users.

Whenever we define how pieces of code are going to interact this should be based on an abstraction that represents the functionality that is going to be consumed, it shouldn't be based on details of how that functionality will be implemented.

As a slightly contrived example, if you wanted to save files you wouldn't expect the interface to do so to talk in terms of disk sectors and binary sequences. You might instead expect to use file and file-writer abstractions to protect you from that complication.

Once your protected from the detail then the implementation can be tweaked, modified or completely rewritten without your code breaking, this is what we mean by loose coupling.

Coupling is a mechanism by which classes are connected to each other and can act as a channel for all sorts of things to be transmitted between them including complexity, defects and breaking changes.

Encapsulate the Concept

A class in your code should represent something in your problem domain, anyone that understands that domain should recognise what the class represents and realise how it can be used.

When this isn't the case and a class only loosely represents a concept developers will end up having head scratching moments where they have to write code where it isn't immediately obvious either why some invisible join between classes has to be made or why a certain piece of functionality lies in a particular place.

Classes that do properly represent a concept are said to have strong cohesion, every line of code in them is all geared towards representing the same concept.

Cohesion is a mechanism by which understanding can be transmitted to a developer looking at your code leading to less head scratching and more productive time building well engineered solutions.

Strong and Loose

Sometime these concepts can get mixed up in developers minds, this isn't surprising since they very often interrelate, a class that operates at a good level of abstraction often also demonstrates good encapsulation.

A good abstraction hides the detail of the implementation by being well focused on representing a single concept within the system which brings us back to encapsulation.

The important thing to remember is that its all about the relationship between code, code inside a class should be very closely related whereas the code between classes should be very loosely related.

If code represents detail this means detail in one class shouldn't relate to or depend on detail in another class, if it does its because an inadequate level of abstraction is failing to hide detail or because bad encapsulation means code that should be together has been split-up.

Spotting which once of these is causing the problem is not always easy and in many ways is the essence of what it means to be an experienced developer but remembering that all these things are interrelated and that detail, complexity and confusion are the enemy is a pretty good start.   

The Scores on the Board

As developers working within an agile team we spend a significant amount of time looking at some kind of sprint board.

We see what's left to do, whats being worked on and what we've completed. All of this helps us tell whether or not were going to achieve our goals.

But is their actually more to see on the board than that? Is it actually possible that the board can tell us something about our code?

Stories Reflect The Code

I'm sure all of us have been in the position where were struggling to see a way through the sprint.

"This story depends on that one, and we can't start that until this one is done" 

Quite often were quick to just write this off as bad luck or bad planning but when this happens over and over again is their something more?

Tightly coupled code will produce tightly coupled stories. If you struggle to break down your code base into elements that can be worked on individually and simultaneously all of your sprints will contain a lot of blocked stories, progress will be slow and much of your resource will be twiddling its thumbs.

This will never be more true then when your sprint involves making changes to an existing part of your system, the extra time taken early on in development to define some robust and flexible interfaces will be paid back here when you can fully utilise everyone in the team can get stuck into making the necessary changes.

This isn't just about the developers either, sprints with a lot of blocking stories will also be hard on testers as it inevitably results in a big bang of delivery to test towards the end of the sprint rather than a gradual stream.

How Many Points?

Even before the sprint starts the quality of our code can influence how smooth the agile process will be.

A major part of pre-sprint activity is pointing the stories which can on occasion be greeted by a large exhaling and puffing of checks from everyone involved.

An inability to point a story can be caused by the story not being well defined or ambiguous but it can equally be caused by the code.

It isn't easy to point stories when the code is large and complex and where the interaction between classes or sub-systems is strongly coupled in a manner that is not easy to penetrate.

In this situation their is also a tendency to be pessimistic adding on a certain margin because were confident things are going to go wrong when we start trying to work with that part of the code base.

This ball of string pointing where we become scared that if we change this everything else is going to come crashing down around us is another sign that the agile process is giving us just as much information about our code then it is about our product and team.

We Still Have Defects

Defects are a fact of life in software development, the business of writing code is too complex for mistakes never to be made and for consequences to always be anticipated.

But this doesn't mean that we should just shrug our shoulders whenever a defect is found. This isn't to say that we should be looking for someone to blame but more that we should be identifying why this particular change to this part of the code is causing so many problems.

This is not only to help understand how we can improve the code base but also to stop fear spreading. A strong desire to not change one particular aspect of the code can lead to bad decisions being made, decisions that from a structural or architectural view don't make sense but simply mean if we do it like this we don't have to touch that.

As with most things in life it best to take your medicine early, if you start seeing signs that something is wrong, no matter where those signs may be coming from take the information on board and plan a remedy.

Agile is indeed the gift that keeps on giving, it not only allows us to effectively streamline and manage our delivery but also gives a lot of feedback on the quality of our code all we have to do is listen.   

Playing Nicely with Each Other

Nearly every app or piece of software of any reasonable size will end up having to integrate with another system, most commonly some kind of server.

This kind of integration can very often be a painful experience, two systems designed to come together seamlessly end up singing from different song sheets.

This pain also often results in aspersions being cast and blame being apportioned, "this is a server issue" or "it all looks fine in our logs".

So are we always doomed to this integration hell or are there things we can do to smooth the road?

Here not Everywhere

First of all integration shouldn't be all pervasive, code you don't control is dangerous, when you integrate with another system the surface area of your code that is exposed to this danger needs to be kept to a minimum.

When explaining the integration you need to be able to draw a circle around the class, package or namespace thats responsible for getting the job done. If you end up having to draw multiple shapes on the page to explain it all your probably just explaining how any changes in the system your integrating with are going to cause large scale destruction in your code.

Its also important, as always, that the integration is represented by a well engineered abstraction within your code. You never want your code to be exposed to details, this is especially true when you don't control those details.

For example you may be making a server call to get user data from a server, the only relevance to the rest of the code is that this data will be retrieved asynchronously from some source, the fact its an HTTP request or a SQL  query is detail. You need to throw another value into the header or adjust the query go right ahead its all in this class here.    

Its Not You Its Me

When it comes to testing your integration its important that your in a position where you can vary one thing at a time.

To go back to our example of making a server call, it should be possible to test your code against an idealised stubbed version of the server, whether this be loading data from a file or a more formal approach that provides some kind of virtualised backend.

Equally its important that on the server end you have some way to exercise your API that doesn't involve the application.

Obviously at some point everything needs to come together but before you leap headlong into it you need to have established some kind of confidence that your code works. If you don't have that confidence when something does go wrong you'll be left shrugging and probably laying the blame with the other guys.

Having this ability to stub or fake the interaction with the other system will also naturally force us to think about the interface, "exactly what is the JSON schema going to be?", "what format do you want us to send that in?". 

Independently Verified

Once we have defined the nature of that interface were in a really good position to practice some TDD and give ourselves another way to prove the integration is working.

As is the case with most things unit tests provide an effective first line of defence against things getting broken and can also be useful in playing out some "what if" scenarios.

We are now able to prove our individual classes work with our unit tests, prove our system as a whole works by using our replacement or fake server before finally attempting to actually integrate.

Despite all of this careful preparation things will still go wrong, quite often because one of the systems fails to comply with the agreed contract, "if I give you this your supposed to give me that".

In order for us to know whats going wrong we need to have identified exactly what that contract is and we need some way of verifying that individual elements when given the correct input will supply the correct output.

This isn't about apportioning blame its about having a way to quickly identify what needs fixing and fixing it, were all in this together after all.     

Telling A Tale of Code

When we become experienced developers there is a subtle change in how we read code, we stop necessarily reading keyword by keyword, variable by variable.

Instead were able to recognise prose we've seen before and appreciate the story being told whether good or bad.

Our ability to do this is dependent upon the care that is taken in trying to tell the story.

An often quoted mantra is "Good code doesn't need comments", while it would be a slightly extreme view point to never write comments its certainly true that good code is readable code and there are certain techniques we can use to maximise this readability without the need of explanation.

Whats In a Name?

All good stories need well defined characters, a skilled author is a master of nouns and verbs, clearly the name of a variable should convey what is being stored and a function should describe what action it will perform.

What can be more subtle is that in neither case should we be describing the how, a variable name shouldn't talk about the underlying data structure and a function name shouldn't expose detail about implementation. For example should a method be called saveToDatabase() or just save()?

Details change and unfortunately there is no inherent mechanism to keep our variable and method names in sync. One form of unreadable code is where you simply cannot tell what is going on, another just as destructive one is where you think you know but the reality is very different.   

Paragraphs and Chapters

No matter how skilled you become at reading code there is a limit to how much code you can interpret in one go.

Another approach to things like the Single Responsibility Principle and Interface Segregation Principle is that they limit the required scope of understanding of the reader.

By dividing and conquering we make our code more readable and understandable because their is less action on the page and less to get our heads round.

Logical structure also means we can take much more as read, if your injecting a dependency called IPersistentStorage that has a well defined CRUD interface I have no need to look into the detail and I don't need to understand anything more than what is on the page.  

Clear and Consistent Voice

In a similar manner to having a logical structure having a clear and consistent voice when writing code will also go a long way to helping others understand your story.

This means a common approach to naming, using similar solutions for similar problems and ensuring that a common plot is running through the whole story.

A common problem when looking at large open source projects is that many people have been involved in its development, each with a different story to tell and a different style and approach.

Individually all these different voices may be clear and logically but when there all layered over each other it suddenly becomes confusing. Navigating around the code base suddenly feels like different chapters from different books.

In many of these situations it doesn't really matter what you do, just always do it that way.

A large amount of comments in a code base is a slight smell, whether its because the writer feels you may not understand this bit or because they want to draw attention to there genius it implies the code itself is not well structured or logical.

This becomes even more prevalent as the code base evolves as the comments get more and more out of date with the code there supposed to explain.

There will be occasions when you really are forced to do something that requires explanation but ultimately nothing is more expressive than the code itself after all its this that defines what the story is and how it will end.  

Square Pegs and Round Holes

When writing unit tests one of the most important things that will determine whether we end up writing good tests or bad tests is how we deal with dependencies.

Bad tests won't properly separate a class from those it uses creating either unstable tests or tests whose results don't actually tell us anything about the health of the class supposedly being exercised. 

It is also very often the case that problems we face with dependencies when trying to test a class are indicative of bad design, testing shouldn't be difficult, but of course your all practising strict TDD and writing the tests first right?

So how can we supply dependencies during tests?

Sucking on a Dummy

A dummy object contains no useful functionality, it is not intended to be used by the class under test but simply by the wonders of polymorphism it can stand in for a dependency.

The fact that a dummy can be used during a test is a big smell, if you aren't going to use this object why am I having to supply it to you? Yes I could potentially pass null but that degrades readability and you have to know that null isn't actually going to break anything.

If your supplying a dummy to a constructor then clearly the class under test doesn't need the dependency to fulfil its role, maybe it does on occasion require that dependency but if its not essential it shouldn't be in the constructor.

If your supplying a dummy to an API then this would suggest you could make the developers life easier by supplying an overload that doesn't require the dependency (internally you can just call the original API passing null). This makes it much clearer how your API should be used requiring the developer to have less implied knowledge about how this all works.  

Faking It

Fakes appear to offer the same functionality as real dependencies but they take a short-cut or cheat in someway, for example supplying JSON from a file rather than calling a server.

Generally this is done to de-couple the code from some outside dependency and give more control over the data the code is working with, they also generally remove any performance factors from influencing how the code behaves.

There are many good situations to use fakes especially when prototyping or trying to debug specific conditions or data, unit testing is generally not one of this situations.

The implementation of fakes is not necessarily simple, this potential complication can add ambiguity to unit testing, this is something to be avoided.

The output of unit testing must be clear and unequivocal, if its red we need to fix the class under test, if its green were all good. Anything that detracts from this simplicity should be removed.    

Stubbing It Out

Stubs are essentially containers for pre-programmed responses to interactions, if X is called return Y, this is regardless of what is passed in the call and how many times that call happens.

They provide no response to APIs where nothing as been put in the container and they carry no expectations on what should and shouldn't happen.

This all leads to the important aspect of stubs, they play no role in deciding whether a test passes or fails.

Stubs should be used to fulfil dependencies where we don't particularly care how the class under test interacts with it, this will generally be because the call does not carry a high overhead and doesn't have any side effects for the system as a whole.

It maybe that we have an API that checks for some environmental condition or retrieves some configuration data, do we really care whether this fairly inconsequential method call is made 2 times or 3 times? Or are we more concerned with the fact that the business logic ends up doing the right thing?

Once again its important that if a test fails then we know for sure we have to fix something, if tests fail because of some trivial function call this detracts from that clear cut view.    

Send in the Mocks

And finally we come to mocks.

Mocks are much like stubs but with one important difference, they do play a role in deciding whether or not tests pass or fail.

Like stubs mocks contain pre-programmed responses to method calls but unlike stubs they do carry expectations on how these methods will be called. With mocks it does matter what methods are called, how often and with what arguments.

Mocks should be used for dependencies where it does matter how the class under test uses them, for example whether we make a server call once or twice or how many times we hit the database is important. 

With the other types of objects we've discussed were more concerned with verifying the output of the class under test, with mocks we are also interested in verifying how it provides that output.

Its a skill to determine the best way that mocks should be used, once again to hammer this point home failing tests have to carry a clear message, being over zealous in using mocks to enforce very strict limitations on the class under test will lead to nagging doubt that maybe the problem is with the test rather than the code being tested.

Its important that unit tests are treated with the same care and attention as our functional code base, this isn't just because were relying on these tests to give our code a clean bill of health but also because they shine a light on issues with our implementation.

When you encounter some difficulty in supplying a dependency to a class under test don't just write this off as being just one of the frustrations of writing tests, instead ask yourself what this tells you about the class your testing.

If your class is a well written loosely coupled class with high cohesion and a well thought out API maybe you shouldn't be having this problem?   

Always Be Solving Problems

Aside from the purely technical explanation what exactly is software?

I believe the most productive way to answer this question is that software solves problems. This may seem like a fairly broad explanation, but even a game could be described as solving the problem of boredom.

I believe this way of thinking enables us to better place ourself in the shoes of the user. Unfortunately I think too often we lose sight of why it is we are producing all this software, we assume we need to produce more and more and we assume too much about how users react to all this.

Users Experience Software

Sometimes we can fall into a trap of viewing User Experience (UX) as a distinct element of software when actually it is more pervasive than that.

UX is not the cherry on the cake its the whole recipe.

UI, features and defects all go to make up the experience users have when they interact with software, the moment we concentrate too much on any one element we degrade this experience.

Nowhere is this more evident than when we let ourselves become entangled in a conveyer belt of new features. Its incredibly easy to spoil a slick UX by muddying the waters by layering more and more features together until there is no longer any clear purpose to what we have created.

We shouldn't see software as an arms race, if we concentrate on one problem and provide a great solution users will come and word will spread.

Its no surprise that some of the most popular and successful apps are very simple propositions, they don't need much explaining and they don't readily add new features if it might harm this central use case (as an example think how long Facebook spent deliberating on the best way to introduce a dislike button).  

Be Platform Agnostic

Its a very common occurrence to hear things like

"We need an app that...."

"We should add something to the website that..."

These things are very often uttered very early on in the development of a solution, but they expose a decision being made about user experience based not on the needs of the user but on the desire to be on trend.

The choice of platform, such as mobile app, website or maybe even not a technical solution at all, should be made based on the how the problem is best solved for the user.

We should instead frame these statements as,

"We want the user to be able to ..."

Sometimes this will naturally point towards a platform, sometimes it will be less obvious, but there is nothing more frustrating as a user than being forced to use an inappropriate platform to fulfil a need.

Cutting Edge Isn't For The Faint of Heart

Development of a solution should always start with the problem, if you pick the right problem this guarantees that you will develop something people want.

Many companies fall into the trap of picking a technology first because they want to be seen as cutting edge and then engaging in a desperate hunt for a problem for this technology to solve.

This inevitably leads to unsatisfying solutions that feel forced, users may initially show enthusiasm for hi-tech cool stuff but if your not solving a problem they care about this will be short lived.

A tell tale sign of this is when too much explanation is required for the user to understand the proposition simply to get to grips with the technology, the best solutions to problems are when we just get it and say "why hasn't someone done this before".

As geeks we see software and technology as an end in and of itself, we code just for the sheer enjoyment of it.

As productive engineers we should be looking to answer questions and solve problems, we should understand that people don't interact with code they experience our solutions.

They don't strive for anything more, if you can't keep them on the hook without cracking out the bells and whistles then your not solving the right problem. 

Don't Get Clever With Me

Bjarne Stroustrup the creator of the C++ programming language is quoted as saying,

"C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off."

I think the point he was making is that a good programming language provides a flexible and powerful tool chest for developers to work with but its equally as easy to create a monster then to create a beautiful elegant piece of software.

An important part of working effectively in any language is to be able to chose the right tool for the job, we don't always need the power tools, sometimes a hammer and some nails will do a perfectly good job.

Lets look at some examples of where trying to be too clever might result in problems.

Tying Yourself Up In Threads

There should always be a healthy amount of scepticism whenever anyone says "we need this to be multi-threaded".

Lets be clear threading itself is not actually that complicated, what can very quickly become incredibly confusing is trying to manage access to data and resource once you have multiple threads of execution.

By using multiple threads you open up a whole new potential stream of defects whilst also simultaneously making your code harder to debug.

Using multiple threads is sometimes seen as the only way to increase performance, this is a slightly skewed way of looking at the problem.

Inefficient code is still inefficient when run in multiple threads and few things are less performant than a deadlocked application.

There are obviously occasions when a multi-threaded environment is necessary but this shouldn't be the default position whenever we encounter a performance problem.      

On Reflection That Wasn't Clever

Reflection is a very cool thing, and quite often once a developer gets a taste for it they see it as the answer to all sorts of questions.

But reflection is quite often inefficient and can have a large negative impact of readability.

Bad use of reflection can be seen when we implement marker interfaces (interfaces with no methods) or when we are told to extend a certain class but not to add or implement any methods.

This leads to code without a clear purpose where readers will ask themselves questions like "what does that mean?", "why are we doing that?"

The type of meta-programming that reflection allows can be incredibly useful but it shouldn't be used to the detriment of well structured code with clear purpose.   

Extending The Problem

Many languages provide the capability to add functionality to existing classes, whether it be categories in objective-c or extension methods in C#.

This can sometimes be very useful to avoid constant copy pasting of some utility function but can also encourage bad practice.

Its very easy when using this kind of feature to create a class with an eclectic mix of functionality with the same class being repeatedly modified to do a job it was never intended to do.

This can lead to a class with an inconsistent API lacking cohesion providing poor abstraction.

If your writing a large number of these methods for a class consider whether you can create a new class more suitable to your needs by using composition, this will lead to greater control of not only the API of the class but the also the internal workings.

The point with all three of these examples is not that any of these aspects of programming are evil more that the scale and complexity of a solution should be in proportion to the size of the problem.

We don't need to always open up the whole toolbox at our disposal, within agile their is the concept of the "simplest thing that could possibly work", this not only produces code that is more easily readable and maintainable but ensures time isn't wasted on premature optimisation or gold plating.

Part of the skill of a craftsmen is in being able to achieve wondrous things with everyday tools by applying hard earned skill and experience, this is just as true in software.

Always start off thinking how do we solve this problem using basic constructs, prefer simplicity before reaching for the industrial strength solutions and make sure your not always looking for an excuse to use that new cool feature.    

Progressively Enhancing Your Apps

Progressive Enhancement (PE) is a web design strategy that concentrates on accessibility to ensure that basic functionality is available to all while making the most of available tools to improve the experience for the user whenever possible.

While the practices involved in PE can't directly be mapped to mobile development some of the principles that it employs certainly can be.

Separation of Concerns

A central concept of PE is that content should be separated from presentation, this application of the Single Responsibility Principle (SRP) by separating concerns can be applied to any area of coding that has a UI it presents to its users.

Within our mobile apps their should be code that generates/retrieves data and their should be code that displays that data, their is no reason for these two areas of code to be aware of each other and each should be able to very independently in its implementation.

Code that deals with data shouldn't care what your intending to do with it, code that presents the data shouldn't care where it comes from.

By separating these things out we limit the impact of change and ensure as much re-use as possible.

For example if each piece of UI code is obtaining data directly and we make a change to how that data should be accessed we suddenly have a large repetitive re-factoring job on our hands.

Control Freak

Within a web environment PE will encourage having has much code as possible in an environment we do control, the server, and minimising the amount of code in an environment we don't control, the browser.  

You may think we'll that doesn't apply to mobile we control all of it?

But do we, how much can we change the structure of our code when were working in the UI layer on iOS or Android? Or is it case that we have to fall in line with our Activities and View Controllers.

Even within mobile we should be trying to create an architecture that puts as much code as possible outside of any platform enforced constraints. We have to tow the line in the UI layer but we are king in our service layer, data layer and any other abstraction we chose to have.

When we interact directly with the OS we not only have less freedom in our architecture we are also exposed to more potential change, the next version of Android or iOS might introduce changes that could break us so lets make sure the surface area of our code exposed to this danger is as small as possible.

Don't Assume Anything

The reason PE exists is because with so many browsers and possible configurations out their you cannot assume anything about the functionality or tooling that may be available.

A common problem in mobile development is when we assume we will always have certain resources available to us, most common of these are internet connectivity and location.

So many apps end up just showing empty screens or white space whenever a call cannot be made to a server or the users location isn't known.

I'm not saying your app has to miraculously work even without internet or if the user cannot be located, but it should anticipate that this situation may arise and keep the user informed as to whats going on and do its best to still offer some level of functionality.

Just because we may work primarily in a certain field of development whether that be mobile, web, database or infrastructure there are still things we can learn taking the basic truth of certain principles and applying them to our particular area.

There's always more to learn as a developer and the best way to tackle certain problems is as a group so take advantage of all that collective knowledge and experience by being open minded about what others with a different perspective can teach you.

Don't Rely On People

An important part of being agile is to be in a near constant state of being ready to ship working software that delivers value to customers.

This means we must have very efficient mechanisms to put the software in peoples hands and just as importantly to verify it is working as intended.

In reality the only way this is achievable is via the effective use of automation, you need talented people to collaborate to construct great software, you need automation to ship great product.

Don't Rely People For Quality

Any production pipeline needs to ensure the quality of the product its producing, first and foremost this comes from employing good people, but even good people can make mistakes and any form of collaboration can result in misunderstanding or differences in approach.

For this reason our pipeline needs certain quality gates to ensure any sub-optimal changes are routed out and fixed and that certain standards are maintained. Traditionally this has been provided manually by things like code reviews and QA testing, if these are your only quality gates you will find it very difficult to be agile and you will ship defects.

Software is complicated, people will make mistakes when their implementing it and people will miss things when they review and test code.

Defects are very often subtle, performing a code review is not like checking someone's spelling or grammar it can be very difficult to truly asses how software will perform purely by reading the source. 

What we need is the cold calculating eye of automation, automated testing and analysis will never miss something because it needs another coffee or because its being distracted by a Product Owner.

Automated quality gates will apply the same rules every time and always take the same amount of time to give code a clean bill of health or point out its failings.

Don't Rely On People For Output

The only way we can be ready to ship at a moments notice is by not needing to be given notice that a build of our code is needed.

Within an agile team their should be no concept of needing to ask someone to put together a build.

Pulling together changes from multiple work streams, coalescing it into one unified body of code and getting it ready to ship is a complicated and potentially time consuming process.

If left up to individuals mistakes will be made and you will find yourself having to ask "is the build ready yet, we need to ship!".

Instead builds and output should just happen, when new code is available it should be incorporated into the product, built, tested and put into peoples hands without anyone lifting a finger.

Once again the machinery of automation will ensure the same unwavering processes are being applied to every single build, all the time.

Let People Be People

So if we shouldn't rely on people to ensure quality or to produce output what should we rely on them for?

Their a certain things we can't automate, we can't automate creativity, we can't automate problem solving and we can't automate enthusiasm to produce value for customers.

We need developers to come up with the engineering that will make our product vision a reality.

We need testers to explore our product, to be the people asking the "What if" questions and be striving to make improvements that will increase the value we're delivering.

In an agile team tasks that are mundane, repetitive and time consuming should be automated, machines are better and faster at these types of tasks and their output will be reliable and unwavering.

For everything else we need to utilise the skills that only people can bring and make sure they can spend the majority of their time utilising these skills.