Over the next month a developer and team lead will be leaving the company where I’m currently working.
Both are big losses.
As a contractor I move around a lot and meet lots of developers. Most are OK, some are good and a few are exceptional and that’s the category the two people leaving fall into. .
This means they can solve problems, contribute constructively, pick the best tool for a job, and understand how important it is to inspect and adapt.
When I did a presentation last month they’re the two people I asked for feedback because I valued their opinion.
So when people like this decide to move on it can leave a company with a problem because if you keep replacing exceptional or even good developers with OK ones something’s gotta give.
Soon cracks could appear and the cost of not holding onto talented developers will become all too apparent.
I’m not saying every developer in a workplace needs to be continually sharpening their sword by questioning and challenging themselves, but without individuals like this a development team will lose their cutting edge and become stale.
So what can organisations do about it?
Given there are only a few rare gems out there, look for developers with potential.
That doesn’t mean finding people based on how many certifications they hold.
Certification means a developer can memorise a framework. It doesn’t mean a developer will know what pattern to use to solve a problem or even approach it.
I can say this because I’m both a Java and Microsoft certified developer.
Also avoid hiring developers who don’t fit the culture of your organisation.
Under no circumstances hire alpha male/diva developers with massive egos and big mouths who want to be the centre of attention.
So if you can find someone who has potential, investment is crucial.
Instead of just sending them on technical training courses, help them start their journey in becoming better developers by sending them to talks and conferences about things like domain driven design, TDD and BDD.
Skills Matter (no affiliation) in the UK have plenty of excellent events/training courses going on, some of which are free.
This way they’ll be able to pass on their knowledge to others and increase the likelihood of you retaining them.
Here’s on one of favourite quotes
What if I train them and they leave? What if you DON’T train them and they stay?
Just like a football team… it can take years to build a good development team that can challenge for the title, but only months to undo the good work and find itself in mid table mediocrity or worst still relegation.
A few months ago after joining the team, there was a lot confusion how a previous project worked.
Stakeholders weren’t sure what functionality had been implemented, testers weren’t sure if everything had been tested and developers didn’t want to go anywhere near the code.
While there was a wiki no one was sure if was 100% accurate which meant it could do more harm than good because it could lead to false assumptions.
As a result of this the relationships between the groups had suffered.
Testers and business owners were open to the idea but were skeptical to how valuable it would be.
So we decided to try it out on a small part of the project.
And it worked!
Working collaboratively we found relationships started to improve and there was a lot more trust between the groups.
At the end of the project stake holders, testers and developers agreed executable specifications were an excellent way to develop software and keen to adopt the approach for other projects.
So what sold executable specifications to the stakeholders, testers and developers?
Scenarios that matched the business problems the stakeholders wanted to solve.
This gave stakeholders confidence and lowered fear and resistance to change.
Easy to read scenarios that matched the domain language the stakeholders were using.
Stakeholders could relate to scenarios and therefore felt involved.
Using scenarios to fill out the blanks.
When the test team or developers found new scenarios they communicated using with stakeholders leaving out what should happen (the then step) for them to fill in.
The use of tables.
Tables allow the reader to visualise the data, reduce reputation and mean you don’t have to cram in lots of words.
For example instead of having
Scenario: Submitting form with invalid password displays error
Given I am on the registration page
When enter the password 'a'
And submit the form
Then I should see the message 'Passwords must be 8 to 16 characters long and include at least one capital letter, one lower case letter, and one number'
and then repeating this for every permutation of invalid passwords, you can do this
Scenario: Entering an invalid password displays error
Given I am on the registration page
When enter the password
| a |
| aaaaaaaa |
| AAAAAAAA |
| aaaaAAAA |
| 12345678 |
| 1234567A |
| 1234567a |
| 12345678aaaaaaaaA |
And submit the form
Then I should see the message 'Passwords must be 8 to 16 characters long and include at least one capital letter, one lower case letter, and one number'
We found this gave us valuable input from stakeholders and testers who were able to come up with scenarios much faster than before.
Living documentation.
Running tests to ensure the scenarios still reflected the behaviour of the system after every code change meant documentation was reliable and accurate.
The future
I’m pleased stakeholders, testers and developers have recognised the value of using BDD, scenarios and executable specifications.
By taking small steps, inspecting and adapting along the way, I hope that more projects I work on can adopt this approach.
One thing that has stuck in my head ever since has been her tip about getting people to draw a picture to represent how the sprint went.
The fact that it’s simple and easy to do is what makes it’s great.
She gave two examples, one was a group of people climbing half way up a very steep mountain and the other was a stretched limousine packed full of people without a driver.
This is definitely worth trying out in your retrospectives becuase it’s an excellent way to lighten the mood and get people contributing.
Whether you decide to keep it anonymous or not is up to you.
Both are big losses.
Executable specifications are scenarios created by developers, testers and stakeholders working in collaboration that check the behaviour of a system every time code is committed. For more information and a podcast about Executable specifications check out this 
