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. 

The Fifth Pillar

Traditionally their are four so called pillars to object oriented programming (OOP), these concepts separate OOP from its procedural counterparts and define what the properties of good code should be and some of the tools we have to achieve them.

"Abstraction, Encapsulation, Inheritance and Polymorphism" 

I think their should be a fifth item on this list or maybe even that one item on that list should be replaced, but before we get to that why are these concepts so important?

Abstraction

Abstraction is about the management of complexity and you could argue is the very reason to write code in the first place, to make something complex simpler.

Proper use of abstraction takes a situation that is complex and gradually simplifies by reducing the amount of the system that is in view at any one time.

As an example, I have an application that needs to save some data, do I want every part of my system that needs to do this to be creating SQL statements and interacting with a database?

Instead I create an abstraction of a data store that exposes basic CRUD functionality, now I'm free to put that data anywhere and by any means, no other part of the system cares because they only deal with the abstraction not the implementation.

Interfaces are the currency of this design by contract approach to abstraction, the loose coupling they provide is the single biggest quality a code base can have, its the path down which testability and maintainability are achieved.

Encapsulation

Encapsulation is sometimes confused with abstraction, but while abstraction is concerned with reducing coupling encapsulation is all about cohesion.

Encapsulation is the vale behind which we hide things that you don't need to concern yourself with, we restrict your access because the information we're hiding should have one authoritative source and not be open to change from many different places.

Imagine we were writing code to hold a database of customer records, does it make sense to store all customer addresses in a single array? Or would it be better to have a customer object that has an address property.

The former has low cohesion because the data and the code that operates upon it are separated, the latter moves them together to encapsulate the concept of a customer.

Polymorphism

Polymorphism is the concept that when you look at a class you can see what you want to see, and what you see maybe different to what others see. 

Polymorphism is the natural consequence of the good use of abstraction and encapsulation, once you only care about the interface to an object you start seeing things that might be very different in the same light because they've agreed to do the same thing.

With our data source abstraction we are able to see a T-SQL, MySQL or even a simple array as one and the same thing.

This indifference to detail is what leads to testability and maintainability, my class sees no difference between a real data source and a mock one in a test, you need to start saving data to the cloud, no problem I don't know what your doing with this stuff anyway, just honour the contract. 

Inheritance

Inheritance is the concept that objects can be derived from other objects, most examples revolve around some kind of data model, a Mercedes is a car which is a vehicle etc.  

Inheritance should be considered OOP's nuclear option.

I've seen more code bases in distress because of the bad use of inheritance then any other reason.

Clearly their is a place for inheritance, the majority of application frameworks rely on it, but when you use it in the wrong place it will kill testability and maintainability in a single stoke.

This improper use is usually driven by the so called "is-a" test being confused with "uses-a", for example is a car an engine or does it use an engine? You don't need to inherit from something because you rely on it, it should only ever be because you are and will always be one of those.

The bad use of inheritance is also a very difficult road to reverse out from, once you've built a web of interdependency it has to be torn down not re-arranged.

Composition

The answer, and in my opinion the fifth pillar, is composition.

Composition isn't a grand concept its simple saying you should build big things from using lots of small things, their doesn't need to be a relationship between them just that one is providing functionality that the other can make use of and combine with others to construct something as big as the sum of its parts.

Their is almost nothing that can't be built using composition and the fact that interactions between objects is based solely on functionality means by design you have created testable and maintainable code. 

Preferring composition over inheritance will very very rarely steer you wrong, don't let inheritance become the crutch you rely on because it can very easily become weak and fragile and not hold your weight any more.

Instead use the strength of composition to build systems with strong abstractions, well encapsulated information and use polymorphism to test all the things and adapt at a moments notice.