More Than Coding

When your starting out in a career in software development its only right that you concentrate on developing your core engineering skills as a coder.

Your primary role is to engineer software and you need to be able to recognise good from bad and have a toolbox of skills you can draw on to build the systems required.

But as you grow into your career certain softer skills start to develop that are important for your growth as an engineer both on a personal level and within the organisation that you are a part of.

These softer skills can easily be overlooked if we assume our only role is to be a techie when actually we need to be more well rounded than that.

Know What You Don't Know

There is a phase in the development of an engineer when their skill is starting to develop that they feel they can conquer any challenge, they are an engineering super hero that will use software to combat all enemies.

Actually no engineer is an expert on everything, no-one has the answer to all questions.

Being a good engineer means having the ability to effectively and efficiently learn how to do something new. Your knowledge and experience makes you able to asses what good and bad looks like, even if you've never seen a technique or approach before you can spot well engineered thought through from the smell of something thats not right.

What is critical is to realise when your knowledge doesn't extend into the area your being asked about, to realise how your going to build that new knowledge and to realise that knowing what you don't know is a skill in itself.

Being a Pragmatist

Another aspect to our developing engineer is to accept no compromise in the application of their engineering skill.

While I would never for one second tell developers that should readily accept incurring technical debt there does also need to be a realisation that software that isn't shipped does nobody any good.

Another skill our developing engineer needs to acquire is a level of pragmatism to know when a compromise needs to be reached between engineering excellence and getting something to users.

The key second aspect to that skill of pragmatism is knowing how to structure the compromise so that it isn't a weight around everyones neck when developing the product further in the future.

Coding something badly is simply bad, knowing when to stop finessing and leaving room for future growth is being an effective engineer.

When Talking to Farmers Talk About Farms

A final awakening for our developer needs to be that they are part of something wider than just developing software.

They have a role to play that is wider than just being a techie they also need to be a communicator whose able to get non-technical people within there organisation to appreciate technical problems and have an appreciation for how the sausage is made.

There is a key difference here between understanding and appreciation, you don't need to teach everyone in the business to code, you instead need to build an appreciation for when a requirement is hard or easy and consequently why a suggestion of a different approach is being made.

You also need to build an understanding of what matters to others in your organisation, understanding there viewpoint while developing the language you need to use to explain how what your doing affects what they want. 

Your role here is to be a technology evangelist building a recognition in those around you of the engineering process whilst not losing sight of the fact that you all need to come together to produce products not just code.

First and foremost you need to become a good engineer capable of producing quality software but always have an eye on the fact that you also need to grow into a well rounded individual who understands all aspects of the business you are in.    

Cogs Not Machines

What does it really mean to construct or devise a software architecture? If we can't answer that question are we just in the code production business or are we following a plan to build something that is greater than the sum of its parts.

We build software to solve a problem but are we also trying to lay the foundations for the solution to the next problem or are we only working in the here and now where we don't worry about tomorrow until it comes. 

With agile practices we've tried to put less emphasis on up-front architecture and bring people down from the ivory tower, so what do we now mean by developing an architecture.

Integrate to Implement

As a software development team we are ultimately tasked with producing something that meets the needs of the user and improves some aspect of their work or play.

However if that is the driver for our architecture then progress from that initial success will require as much effort as the first step we took.

If we construct a monolith of code aimed at solving the problem put in front of us then each subsequent problem will be just as hard to answer.

Implementation should be limited to the cogs that will, via integration, be used to form a problem solving machine. If we achieve this the solution to the next problem may very well require no implementation we instead repeat the integration phase with minor tweaks to the blueprint of the machine.

Re-Use without Re-Compilation

In essence what we are describing is code re-use, but critically this must be achieved without the need for re-compilation.

Some are happy that re-use can be achieved by copy and paste.

What is actually being achieved by this operation is re-use of thought, not re-use of code.

Whoever is copying and pasting the code is simply not having to expend any grey cells on working out a solution to whatever problem they have, the code itself is being duplicated and re-compiled.

If we construct our code into re-useable units, whether we call them libraries, packages or frameworks, we achieve re-use of both thought and code without the need for re-compilation.

We have created a situation where we can build many machines from the same cogs.

Re-Configuration without Re-Compilation

We may construct a piece of code that successfully consumes an API or integrates with a sub-system and this leads us to conclude that we can know integrate with any such system by simply re-configuring the code to a different end-point or URL.

But its important that if this re-configuration is achieved by changing the code then actually what we are producing is slightly modified software not re-using what we already had, this process would have to be repeated multiple times.

Once again re-compilation is not what we want to be doing, all good developers have a healthy laziness that means they'd rather be able to ship exactly what they shipped last time then go to the effort of producing more, slightly modified, software. 

So to go back to our original question, constructing a software architecture is to increase the opportunity for the re-use of effort, thought and code without modification or change.

It should be based on a lethargy that makes us reluctant to want to hit the build button and instead want to point you at the package we've already produced that fits the bill.  

Mobile DevOps

The DevOps movement is a natural extension to the application of agile principles.

If we are good at writing software and utilising IT why would we not complete the circle and use these skills to help us deliver our products.

If you work in mobile development sometimes this can seem like a foreign land, the way we build and deploy software can on first inspection not seem to fit with these ideas but its simple a matter of degrees, we can achieve the same results.

Always Ready to Ship

One principle of DevOps is to have a continuous pipeline to enable the delivery of features into production.

Anyone who has ever submitted an app to the app stores would say this isn't a realistic dream, we cannot submit multiple updates to an app on a daily basis whenever a new piece of code is finished.

But the key here is to realise that the ability to deploy at a moments notice is actually a side-effect of the real benefit we gain from automating our delivery pipeline, and that is certainty about the state of our code.

By consistently and automatically building, testing and analysing our code on every change we always know the health of our application.

If the change makes it through the pipeline we still have an app that is ready to ship but now with added functionality. However, if the change doesn't make it through we still have work to do to deliver that feature and we fall back to the last known good version of the product, which may only be hours old.

We never again will have panic setting in when we're told we need to get a new version out.

Always Ready To Code

So now we can ship whenever we chose what features and improvements do we want in our next release?

Users interaction with software can be unpredictable and not necessarily logically, this is no less true for mobile development.

As agile practitioners we don't try to out think our users, we make a reasonable guess about what we think they want and ship the minimum implementation of that idea, we also expect that guess to be at least partly incorrect.

We detect our mistake by observing our users interacting with what we have built, not by standing over their shoulder but by having our app call home.

Asking one user what they think of what has been produced will not be informative, asking many of them might give a clearer picture but asking every single user all the time gives us a total and thorough view of where we are.

Implementing instrumentation and analytics can provides us with the data to drive our continuous pipeline to deliver a slightly improved experience, when we iterate through many cycles of this feedback we will have moved a long distance from where we were towards satisfying our users.

Always Ready To Work

Its important to realise that DevOps is not actually concerned purely with making our users lives better.

Its actually about realising that within our team we have the people with the skills who can make our users lives better and therefore we should remove all obstacles to allowing that talented team to deliver.

If we make the lives of our developers and testers easier we will maximise their output in the form of new features being delivered to users.

This is as true for mobile development as for any other form of software engineering.

Identify what is causing you pain in the process of trying to deliver your product, then confront it head on.

In many instances technology and software will be the key to reliving you from this pain and fortunately you have a team of people that excel at using and creating technology, you just need to remove what is in their way.  

Minimum Viable Engineering

Implementing a Continuous Delivery (CD) pipeline means automating to a large extend the decision on when to ship.

Not everyone will be brave enough to completely remove a person from the process but if we are to achieve anything like a continuous deployment of functionality that person will be basing the decision on the red or green lights of our automated testing.

So how do we build this framework of automated testing how do we know when our code is good enough to ship.

Minimum Viable Code

Code is the building block on which we build our product, the first tranche of testing needs to ensure that each of these blocks does what it claims to do, we determine this via unit testing.

If we have adequate coverage of our code from unit testing then we know that we can safely compose our system with confidence that when tested in isolation each of our building blocks is fit for purpose.

If we've followed TDD we also know that this isn't by fluke, we have seen the tests fail and now were seeing the tests pass.

By integrating unit testing into our CD pipeline we can be confident that problems at this level will be detected early, the higher the frequency of change in your code base the higher the need for this testing to be automated. 

Minimum Viable System

Just because we have developed trust in our individual building blocks doesn't necessarily mean we can build our jigsaw and just assume everything will be ok.

Part of our engineering skill is in being able to orchestrate these building blocks into a system that achieves a goal, this might be to manage a database, consume an API or process some data.

We now need to move from testing the building blocks in isolation to testing them when they are chained together.

During unit testing the interaction of code with its dependencies takes place in a controlled but simulated fashion, now we need to ensure that end to end processes give the desired result.

We have now moved from building blocks to sub-systems and verified that under the hood our code works.

Minimum Viable Product

The majority of us will be constructing software that people interact with, we provide a user experience where inputs from our users trigger behaviour within our code base resulting in output to be consumed.

Our final level of testing needs to assume the place of our users and ensure that given a certain circumstance, when a certain action is taken, then a certain result is observed.

This behaviour driven testing is the final step that determines whether or not we have something viable to ship.

A green light from those tests needs to be interpreted that we have something delivering the minimum our users expect, a red light should mean everyone stops until the problem is discovered and fixed.

We have now tested our product end to end, if we've done this on a regular automated basis then we have established several points at which we could ship.

Software is complicated, manually testing an entire product is a lengthy error prone process.

The only way to be able to deliver regularly and often is to automate as much as possible, freeing up your human resource to concentrate on more abstract elements such as edge cases and unusual activity.

Software is very good at dealing with the repetitious and mudane we should use that to ensure our code, at all levels, is continually being tested whenever change takes place. 

Start Me Up

Many large and successful companies will often look at smaller enterprises with an envious eye.

The flexibility and freedom afforded to them can often lead to the pronouncement that we need to "think like a start-up", but what exactly is the state of mind were trying to instil?

And conversely if you're a start-up what are you trying not to lose as you grow and hopefully become successful?

Risky Business

Start-ups have a healthy attitude to risk, this is not to say they are irresponsible or reckless but that they realise some details will need to be figured out along the way.

When working in technology as a small company time is not always on your side, their just isn't time to come up with a full-proof plan, instead you have to have faith that the core of your idea is sound and you and your team are smart enough to figure the rest out.

In a similar vein you need to be able to recognise when a decision isn't working out and find a new way. 

Whats most important is to anticipate this potential for failure and be prepared to re-think things and have a plan B in the wings.

Open to Innovation

Many start-ups have limited resources or are at least are trying to maximise the return on what they do have.

This often means they are willing to be active participants in the technology community where many cutting edge technologies are available for free in the form of open source projects.

This openness to innovation, coupled with an accepting attitude towards risk, can lead to very impressive things being achieved on limited budgets.

The majority of start-ups realise that they aren't selling secret sauce, they aren't in the business of producing code they're in the business of providing solutions.

Buying a Ticket to the Game

The most successful start-ups realise its better to be in the market place potentially making mistakes then being on the outside looking in with amazing plans for success but no execution.

To do this these start-ups embrace the concept of a Minimum Viable Product (MVP) and the speed of advancement that comes from rapid iteration.

If your start-up is to be successful then the core of your idea needs to be what users want, without bells and whistles, if that doesn't deliver value adding more and more on top wont rescue the situation.

The only way to validate your idea is to have it in the market place being used.

Your healthy attitude to risk means your accepting of the fact their will be some element of failure in your idea but by iterating and introducing more innovation you will progress.

Thinking like a start-up should mean accepting that not everything can be solved in advance

A healthy agile mind set means embracing the fact that this means not everything we ship will hit the mark with users but that its more important that we're heading in the right direction and evolving at pace.    

Becoming a Senior Citizen

When you've spent a certain amount of time working in development whether formally or informally you will eventually be faced with the transition of becoming a senior member of the team.

But what exactly does that mean? What are the qualities that define a lead or senior developer?

Battle Scars 

The most obvious answer to this is experience, but this isn't just about time on the clock, its important that you've experienced failure.

The most beneficial aspect of experience is the painful memory of when you made a mistake in production or introduced a bad defect.

The desire to not repeat this experience will provide an in-built mechanism to detect when the same or similar mistakes are being made by yourself or others. 

The truly enlightened, and therefore lazy developer, will devise a mechanism to automate this oversight.  

Nobody want to screw up but a developer who regales you with a long story of success has either never stretched themselves or is oblivious to the errors or blunders they've introduced and therefore doomed to not improve.

Teaching All The Things

As a senior developer you aren't a one many army. Good developers will often have a natural desire to want to take on more and more work because they can see what should be done and how.

But an important part of a senior role is education, the goal should be for all members of the team to get the support and advice they need to also grow into becoming an experienced, productive and rounded developer.

This balance is not always easy, things still need to get done. But by recognising an opportunity for learning you'll help others progress, an important aspect to this is the elimination of a blame culture.

If mistakes are an important learning tool then when they inevitably happen they should be viewed in this light, this is made harder if a fear exists around taking ownership of a problem.

A senior developer should also be aware that this education is a two way street, good ideas can come from anyone in the team regardless of their time served. 

That'll Probably Do 

To be pragmatic is to be reasonable about the reality your facing and not dealing totally in the theoretical.

Software can very rarely be considered finished, instead it reaches certain stakes in the ground that represent the next release.

The perfectionism that good developers often hold can lead to a stagnation that causes a slow down in us reaching these points.

While quality should never be compromised to satisfy a deadline, an important skill for a senior developer is to recognise when something has reached its first iteration, it may not be perfect but it does what we need and has been constructed in such a way as to allow future iterations. 

Ultimately we do this to provide something to our users and we have to be pragmatic enough to realise when we've reached a stage where we can do this even if perfection is still a way in the distance.

I don't think senior developers are made just because of a change in their job title, they naturally evolve as they experience more and more of the development life cycle.

They are a product of their mistakes, the knowledge they gained in how things should and shouldn't be done and of the education handed down to them from the other team members they've worked with.

Agile Delivery

Agile software development is based on twelve core principles, while all twelve play a role in improving how an organisation produces software two in particular are key to understanding how we should view the world and our place in it.

Customer satisfaction by early and continuous delivery of valuable software

Working software is the principal measure of progress

Taken together, these two statements mean our goal as developers should be the continual delivery of working software.

By following certain principles we can engrain this thinking into us and the organisations we work in.

No Second Guessing

If we are to deliver software continually to users the processes we use must be automated and trusted.

Does it work?

Have we tested it?

Will it work in production?

Questions like those above must be eliminated from our thinking, our build chains must be built to automatically verify the correctness of software as its produced, to automatically create builds for every environment and for the differences between these environments to be minimal and controlled.

While your second guessing whether your ready for production your agile rivals are shipping to their customers.

While no one wants to put something into production that isn't ready or adequate this judgement must be a repeatable, reliable and ultimately fast process.

Looking for a Fight

Its only natural when we start this journey towards automation of all the things that we start by concentrating on the low hanging fruit and avoid the difficult things.

Actually if we want to reach the nirvana of a slick streamlined delivery process we should be doing precisely the opposite, we should concentrate on the most difficult things causing us the most pain.

Necessity is the mother of invention, if we inflict pain on ourselves by continually doing the things which we find hardest we will find a way to automate them.

Developers are very resourceful people but ultimately lazy, they will concentrate their ingenuity on making their lives easier and what makes their life easier will get software out of the door to users quicker.

Quality Above all Things

As you increase the speed at which your shipping software you will become ever more dependent on quality being built in.

Ensuring quality must not require conscious thought it should be an inevitable consequence of the processes you have in place.

Every commit, merge and build must be tested, if all lights are green we are good to proceed, if anything is red then nothing moves until its fixed.

Pragmatism is an important skill for a developer to have but this needs to be related to what features get shipped not to the quality of the code that makes it out into the wild.

Compromising on quality is an acceptance of shipping bugs, the cost of these bugs in production will always be higher than if time were taken to address them before hand, the short term gain in shipping early will ultimately be undone by the addtional time taken to sort out the mess.

Agile delivery is a fine balancing act between speed and maintaining the integrity of the product.

The only answer is automation that concentrates heavily on addressing the sticking points in the process with a serious bias towards testing at every stage to ensure quality is guaranteed.

Going to production should not be an onerous or scary prospect it needs to be a constant option open to us whenever we feel we've achieved something the user can benefit from. 

End of the Gold Rush

When you tell people you develop mobile apps your very often told, often in hushed tones, about a great idea for an app.

Usually these ideas are interesting and are apps you think you would like to use, but are they a route to a gold mine for the inventors, sadly most times they aren't.

A few years ago we were taking part in an app store gold rush, a well designed app with a cool name and a striking look would command large sums of investment.

Those times have now passed, the gold rush is over and monetising mobile is not a straightforward challenge to meet.

No Secret Sauce

Software is increasingly being regarded as a commodity, its simply the raw material coming off the development production line.

While this view is flawed it has meant that the market often places very little value on code, the majority of apps are now free or carry a small nominal fee.

No longer are we purveying secret sauce, consumers aren't paying for the cleverness of your code there subscribing to the service your offering.

Aside from the possible exception of gaming your aren't going to get rich simply by producing an app.

Advertising Failure

When faced with this challenge many turn to advertising, it is the cure to all ills, when were not sure how we extract the value from the product were producing we fall back to the warm comfort of advertising.

Unfortunately what we very often lose sight of is the context in which the adverts are shown. We've all used apps where we are aware of a banner ad at the bottom of the screen but do we actual look at the advert?

Advertising without context degenerates into a pure numbers game, if we show it to enough people we may by pure fluke get someone who is interested in the product or service to look at and maybe even click the advert.

This is not optimum for anyone involved, the users who are forced to lose screen real estate to adverts, the advertiser with an uncertain audience and the developer who can only make money at enormous scale.

But what about if we did have context, if we display helpful suggestions and not adverts, what if we knew who our customers are.

The Devils in the Data

Mobile phones are an integral part of almost everyones lives, we have it with us all the time and we regularly consult it when making decisions or turn to it when we have some time to waste.

All of this means our phones can detect almost everything were doing in our lives, apps that can harness this and use it to both the developers and users advantage will truly be data gold mining.

This data has the potential to lead to enormous value that we could never have realised simply by putting a price on our app. 

I would never want to put anybody off from taking a crack at the app store but people should do this in the knowledge that very few will make their fortune.

Don't go looking for gold in the hills just have fun in creating something that you feel will entertain or enhance and take it from their, you may just have invented the next big thing, time will tell but you'll have enjoyed creating it regardless.  

What's the Point?

Anyone who has worked in an agile team will be familiar with the concept of agile pointing, seeing everyone in the team holding up cards and declaring an item of work to be 5 points, 8 points, 13 points....

But why do we estimate like this? Wouldn't it give more certainty to the business if we gave an estimate based on time?

Well we do have our reasons, there is a point to pointing.

I'm Almost Done

People are generally bad at giving absolute estimates, developers will often be overly optimistic about how long something is going to take to code.

We are however much better at relative estimation, we can identify that one piece will require more effort than another and we may even be able to apply some kind of scale, its half as difficult or twice as complicated.

Moving towards this unit-less relative approach concentrates the mind on blockers or issues that are causing this increase in points.

This relative measure will also carry more historical significance, knowing that a similar task took 5 days to complete six months ago has very context in the here and now as the team may have been operating under very different conditions.    

Velocity towards Success

Using points based estimation forces all planning to be based on measuring the teams past performance, what we usually deem their velocity.

This focuses the mind on how the teams performance can be improved and the longer the team work together the more accurate this measure of their performance will become.

Two week sprints always contain two weeks worth of effort from the team, the focus should be on how the amount the team can deliver in that period can be optimised.

Estimating in days can very quickly lead to the flawed mathematics of man days.

A scrum team should be viewed as a team and not a collection of individuals, the team achieve things and this can be made to add up to more than just the number of hours they spend in the office.  

Playing as a Team

A scrum team will very often be made up of a mix of individuals with differing experience, ability and skill sets.

Given this mix the amount of time a task takes an individual in the team may vary but team members are more likely to agree on the relative complexity between different work items.

This focus on relativism helps turn planning sessions into opportunities for education and debate and allow the team to come up with an estimate every member is comfortable with.

Once again adoption of agile requires a certain amount of truth to be swallowed.

Ideally a team would be able to give a precise time based estimate to aid business planning but this will simply never be the case, there are too many variables.

Agile is also about continual improvement, not just of the code but also of the team.

Pointing provokes debate and provides a metric to be optimised, it recognises the fact that individuals can run into problems or miscalculate but a team is stronger and can flourish into an effective code producing machine.   

Scaling the Heights

The production of software is increasingly becoming viewed like any other commodity with unfortunately little inherent value being placed on the code itself.

What this means is that unless your doing something very clever the only way to generate income from a technology business is scale, if your able to offer a service to the masses you can start to leverage some profit from your developers efforts.

Scaleability is a property of a code base in its own right and as such needs its own consideration, it won't just happen you have to anticipate what will happen when this system is getting intensively used and what problems only arise when your product is being used at scale.

Delivering on Your Promises

The first piece of software you drop into the market is only the first step, you can't even see the mountain at this stage let alone start to climb it.

From then on you most deliver consistently on an increasing cadence, not only new features but fixing defects, plugging holes and increasing performance.

The only way to achieve this pipeline is via automation, the days of a prolonged development cycle followed by protracted regression testing are over, someone else will fill the void your leaving before your ready to ship.

If your organisation is putting large amounts of conscious effort into deployment you run the risk of solving yesterdays problem when your software does eventually drop, instead deployment needs to become such a regular occurrence as to become mudane.

Diagnosing the Patient

When you've deployed a system at scale you can't afford to be reactive, you have to proactively monitors its health, by the time users start reporting a problem it has already become detrimental.

Careful thought should be put into what data, statistics and indicators can be drawn from a system.

This process should be entirely data driven, no presumptions should be made about what the data will show or what we want it to show, collect the data and learn the lessons it teaches don't try and force it in a particular direction.

When this data tells us about potential problems or possible improvements we need to factor this into our plans as no matter what we may think is happening that data represents reality. 

Securing the Castle

As your user base grows so does the level of trust those users are putting in your service, and unfortunately your success will bring attention from those that wish to break that trust and separate you from the data you hold.

Its important to realise that this is about more than just securing the data pertaining to the service your offering but protecting the user in general.

Many of your users will being using the same passwords and credentials across multiple services and they won't forgive you being the weak link in the chain that exposes it all.

Security and users privacy must be a consideration in everything you do and its even more important in this aspect that you are proactive and not reactive, waiting until there is a breach is too late.

Many of the things you need to consider when scaling your system are the same as when you first built it they simply scale in proportion to your business. But some problems are unique to a system with an increasing user base.

These are problems we are all striving to have as we aim for success but we do still need to supply answers and anticipate them rather than being caught out by users actually liking what where doing.