Imposter Identification

Have you ever had the feeling that your faking it? That sooner or later your colleagues are going to find you out?

These feelings are more common then you may think even amongst those that most would say are high achievers in their field and is often referred to as Imposter Syndrome.

So how can you determine if you are a fraud or whether you are exhibiting Imposter Syndrome?

Known Unknowns

The mere fact that you think you may be an imposter is a good indication that you aren't.

The chances are that you've based this presumption on a perceived lack of knowledge in one or many areas, it actually takes a mature and experienced outlook to recognise when your current levels of expertise don't extend into a particular field.

You perceive a lack of knowledge because you understand your subject matter enough to recognise the subtleties of a task, this is something very often lacking in those that are less gifted or inexperienced, instead they assume that every new area can be tamed using the same limited toolset currently at their disposable.

No Such Things as Experts

There are very few real experts in the world, people that understand their chosen field in its entirety and whose prowess cannot be questioned, the rest of us are trying to become s reasonable facsimile of such a person.

If your asked a question you weren't prepared for your skill and knowledge will mean the educated guess you provide as an answer will likely be good enough with any inaccuracies being minor and not pertinent to the overall correctness of the point you are making.

If you genuinely don't know the answer your skill will enable you to be effective in using the tools available to you to find the answer, you will recognise the phony and be able to spot the truth.

Don't beat yourself up if you occasionally have to tell someone you'll get back them or that your not 100% certain about something, you are more than just a search engine in human form you understand the essence of your subject matter if not every minutiae.

Mistakes Maketh The Man

We've all made mistakes, while some are bigger than others no-one is immune.

The cost is not the mistake itself its the fallout and the knock on effects they often have, the key to reducing these impacts is to be able to recognise early that a mistake may have been made.

This will often present itself as the sixth sense experienced develops have when something doesn't feel right or where an unreasonably amount of difficulties are being encountered.

It can also be seen in the feeling that something is being achieved too easily and the distrust of things working by magic.

A master of their craft is not someone who never mistakes, they are someone who can recognise early the error of their ways and reverse direction, often this gives the impression a mistake was never made because the desired outcomes were achieved but the mis-step was still there.

Working in IT is an intellectual pursuit, sometimes the pressure to have answers and be the one to provide solutions can manifest itself in a distrust of ones own judgement or a feeling of inadequacy when more than a moments thought is required.

Take solace in the fact that what you do is hard, sometimes things can come so easily to us that we think anyone could do it when the reality is quite different.

The fact that you sometimes question if you are doing a good job emphasises that you know what good looks like and the fact that you try harder means that you have the drive and determination to achieve it.

Also realise that at one time or another all of your colleagues will have experienced similar feelings, if they say they haven't then they are the imposters.

Scaling Out Delivery

As agile becomes more widely adopted by organisations both large and small inevitably questions are asked as to how this can work at scale, we have seen the birth of this phenomena with the advent of various frameworks built around the concept of agile at scale.

I believe the thinking around several of these frameworks is flawed and moves us further away from the pillars of agile that attracted us to it in the first place.

Segmenting the Orange

The thirst to adopt agile at scale is mostly fuelled by the results that are seen when using it at a smaller scale, the key thing to keep in mind when trying to grow that success is recognising what it is we are actually trying to scale.

It is very easy here to fall into the trap of assuming benefits of scale in software development that simply don't exist, the purpose of trying to scale out agile delivery shouldn't be about trying to justify the addition of more developers.

Without proper segmentation of the deliveries they are working on having multiple teams of a handful of members is no different to having one large team.

The reason to create a new team shouldn't be to justify adding more developers to a project whilst paying lip service to the idea that a efficient team has a maximum number of participants.

The reason to create a new team is because we have identified an independent delivery of software that can be worked on in isolation, divide and conquer is an old adage but its applications are many.

Obviously in the long term teams will need to consume the output of what the others are working on but the aim should be to maximise the number of different areas that can be under active development without creating inter-dependency between teams to deliver over the short term.

We are trying to grow the number of distinct outputs of teams not the amount of output in any one particular area.

The Grand Plan

As the scale of development increases there will be an increasing need for some co-ordination, which one could call planning, to be in place to ensure everyone moves towards a common target.

When trying to scale agile it can be very tempting for the waterfall illusion of control to creep back into our thinking.

The co-ordination thats established between teams has to be of a loose nature that has the ability to flex with changing circumstances.

This always carries negative connotations assuming this means expect things to be late but actually it can be positive, an agile mindset is very much to ship when something is shippable.

Better segregation between the deliveries of teams can enable a multitude of different cadences of iteration to be in place where opportunities to ship present themselves more frequently not less, not all will be visible or obvious to the user but all will move the product forward.

Philosophy not Frameworks

Needing to find ways to work at scale is an inevitable reality but its important to distinguish mechanics from mindsets.

Agile is not a framework for software development it is a philosophy, a mindset, a way of thinking.

Quite often some of the pillars of agile such as face to face communication or the preference for working software over documentation are the first things to suffer when we are trying supersize our organisation.

Its therefore important that whatever the mechanism we use to scale out delivery we recognise when we are betraying the principles that as agile practitioners we are supposed to hold dear.

One of the best ways to adhere to this is to make sure practices don't become rigid and that we continue to garner feedback and input from the those at the coal face.

We must avoid the temptation of thinking that to operate in an agile way at scale requires a different approach to adopting agile at any other time.

We don't need to re-invent the wheel or go back to the drawing board, the principles of the agile manifesto still hold and our job is to ensure they aren't eroded as the number of participants grows and the allure of falling back into a waterfall pattern become attractive.

Open Source Musings

Developers have a long history of sharing the fruits of their labours with each other, as software development became a commercial activity and not just for hobbyists this concept of sharing was eroded.

In the later 90's several organisations were founded to promote the concept of open source software to not only share code but to commit to developing it in the open for everyone to see and contribute too.

Open source is now a core part of the software development ecosystem with everybody from backroom coders to large enterprises consuming it and contributing to it.

So is using open source now a no-brainer, a moral obligation? As with most things it depends, there are benefits and disadvantages.

Free at the Point of Need

The most obvious benefit to open source is that it is generally free to consume. Aside from the obvious, this removal of a barrier to entry can foster increased innovation and enable the faster development of new ideas.

However its important to remember that free doesn't mean unlicensed, whether it be MIT, LGPL or BSD the majority of open source projects will come with licensing requirements before they can be used and its important to pay attention as to whether or not this fits with the project your working on.

The absence of a license is also not necessarily a good thing as it means a lack of an agreement between you and the writer of the code over acceptable use.

Finally being free means you have to adjust your expectations on some of the services you might expect when dealing with proprietary software, once of which is support.

While many major open source projects have a thriving community if your project becomes over reliant on a small open source library it may not be reasonable to expect round the clock support, you have to be prepared to take responsibility and dive into the code base yourself.

Flexibility to Break

A major benefit of open source is the freedom it allows to take something that is close to what you need and adapt it or add that killer piece of functionality that you think would really increase its usefulness.

The ability to see under the hood can provide inspiration to see many different ways something could be improved as well as enabling you see the solution to that bug that has been causing you a headache.

However in software development where there is change there is always the potential for instability and the threat of complication being introduced.

When assessing an open source project take the time to look into the community behind it and look to see how the project has evolved.

Does the project have a history of uncontrolled change causing instability or is there clear leadership within the community to steer the ship in the right direction?

An open source project is more than just the bits and bytes of the code itself its about the community of people who drive this code base, if the project becomes important to you these people will be as much your colleagues as anyone within your own organisation.

A Change of Perspective

In a traditional commercial approach to software development the code itself is a means to an end, part of an overall package being sold to the end users who require the features it implements.

In an open source project this view point changes, the code becomes very much centre stage, when your users are developers it brings a different mindset.

Developers are details people, they are more likely to concentrate efforts on an optimisation or an improvement in quality.

Developers are also generally opinionated people who have a well defined perspective on how they apply their craft.

Whereas the commercial development of a software based product is likely to be governed by the drive for new features for end users, the development of an open source project is much more focused on the needs and wants of the developers that intend to use the publicly available code base.

This change of focus doesn't necessarily have to be labelled good or bad it is simply different and what attracts many to open source projects. As with any venture that is collaborative it means that not everything will go in the direction you want it to.

Open source has many advantages and its introduction into the software development ecosystem is to be welcomed but the choice to use it should be taken based on more than just the fact that the code being made available can fix your problem.

It should also be based on an intention to engage with the community that supports it and to realise that although the software is free it comes with certain responsibilities to play a role within that community.

The collaborative nature of software engineers is admirable and we are fortunate that sharing the code that represents our currency can be made so straight forward but whenever you embark on a new journey it is advisable to look before you leap.