If you’re looking to get more out of your organisation’s software developers, increase your ROI, spend less money on fixing bugs or increase your development team’s business value release rate, this session is for you. Or you might be a software developer looking to lift your game to the next level.
There are many ways to lift software developers’ productivity and, as a result, the development team’s total output. This session addresses some quick wins, as well as some that take longer to implement.
##############################################################
Maximising Quality with Least Spent: http://blog.binarymist.net/2012/03/24/how-to-optimise-your-testing-effort/
##############################################################
* Improving quality is the best way to increase productivity
Emphasize quality at the end of your project and you emphasize system testing.
Emphasize quality in the middle of your project and you emphasize construction practices.
Emphasize quality at the beginning of your project and you plan for, require, and design a
high-quality product.
Detect errors at the stage when they are least time consuming and costly to correct.
* Bring the quality focus up front. It's much cheaper there
##############################################################
Maximising Quality with Least Spent
##############################################################
Average cost of fixing defects based on when they're introduced vs when they're detected.
##############################################################
Maximising Quality with Least Spent
##############################################################
TDD is not about testing right? It's about creating testable code,
thus allowing components to move independently because we're programming to interface rather than implementation.
Giving us the ability to reason about our code.
Gojko Adzic: Specification by Example.
##############################################################
Maximising Quality with Least Spent
##############################################################
OpenSSL Heartbleed and Apples goto fail
Could have been prevented if TDD was used.
Mike Bland performed a study and POC on this: Chopping the code up into small units.
##############################################################
Maximising Quality with Least Spent
##############################################################
Cost vs Value to the business
##############################################################
Maximising Quality with Least Spent
##############################################################
Based on your Coding standards and guidelines review all code written.
Whether you use a tool to help organise or send emails etc for small teams may work for you.
Favour one on one review over group reviews.
Are we reviewing the external libraries we depend on?
##############################################################
Maximising Quality with Least Spent
##############################################################
Getting the small things established and agreed on, so you can move on and concentrate on the big wins.
If you can't agree on the simple things, you'll never agree on the more complex topics.
Bin dir example.
##############################################################
Maximising Quality with Least Spent
##############################################################
Designs don't spring fully formed directly from someones brain.
Evolve and improve through design reviews, informal discussions, writing and changing the code.
Design is about tradeoffs and priorities
Design involves restrictions
Design is nondeterministic.
3 groups of developers will design something completely different to solve the same problem.
Design is a heuristic process.
Sometimes techniques will work for a specific problem, sometimes they won't.
One size never fits all.
##############################################################
People: http://blog.binarymist.net/2014/01/25/essentials-for-creating-and-maintaining-a-high-performance-development-team/
##############################################################
* Top Talent
Get the best people you can find and afford.
Use less of them.
Don't make your selections based on who can be hired the fastest.
Aim to hire developers with the best habits and a solid history of producing great software.
Do they blog? If so review it.
Do they participate in open source development? If so review their code.
Get the people that have high levels of passion and drive
Passion is infectious.
* 10 - 1 Productivity
Fact:
Productivity of individual programmers with similar levels of experience varies by a factor
of at least 10 to 1.
Teams are a factor of 2.5 to 1
or in other studies 3, 4, 5 to 1.
* Going Rogue
If you've got team members that don't work well with the team,
work on getting them to improve.
If their attitude is just wrong, get rid of them as fast as possible and learn from the mistake.
Misfits will undermine the morale and motivation of the rest of the team and often cause
the better programmers to leave.
* What do the Most Productive Programmers Look like?
We're looking for sustainable productivity.
Professional developers trump your code monkeys.
In my experience, you've got to be one to know one.
You've got to build relationship with them. Understand what makes them tick.
Leave code base in better state than they found it.
Raise alarm bells when technical debt is getting out of control.
Conscious of how readable/maintainable their code is.
Drive designs with unit tests.
Code added on top of code monkey's code starts to exhibit hard to track and replicate bugs.
##############################################################
Soft Tooling, Processes & Practices, Why it Matters
##############################################################
* Distributed Communication & Collaboration
Distributed teams allow us to obtain the best talent no matter where it is.
Developers setup their own office space to what works best for them.
Push to talk:
Mumble,
Sqwiggle (presence snapshots, file sharing, low bandwidth, group chat/video)
Free for teams up to 3 users. $9 per month per user.
Diagrams:
Google Drawing, draw.io, lots of others
Online Code Editors:
hackpad, firepad, jsfiddle, etc
IDE's:
Cloud9, CodePen, Codio, Repl,
There really is no excuse not to get our comms working efficiently.
* Version Control
Distributed
* Work Item Tracking
Scrum gives us the Product Backlog and the Sprint Backlog.
User Stories as Product Backlog items are excellent for:
promoting discussion which fleshes out the details.
Used to spawn Test Conditions which is where the details live.
* Wiki
Must be intuitive for all to use. Managers, developers, CEO's
* Build System
Continuous Integration running your unit tests,
Nightly Build running your longer running tests
##############################################################
Hard Tooling, Why it Matters: http://blog.binarymist.net/2013/03/02/how-to-increase-software-developer-productivity/
##############################################################
2560 x 1440 LED
Flow
##############################################################
Hard Tooling, Why it Matters
##############################################################
We multi task now more than we ever have before.
SSD's, Memory
##############################################################
Hard Tooling, Why it Matters
##############################################################
Want your devs to get lots done.
Well, they're going to spend a lot of time sitting in a chair.
Want to keep them there?
Buy good chairs.
Standup desks
Let the team decide how to decorate and fit their office.
##############################################################
Continuity of Delivery
##############################################################
* CI: http://blog.binarymist.net/2014/02/22/automating-specification-by-example-for-net/
Again, you must have CI running. Even if you start small, just get it building your code.
Then start to add extra steps, tests, git hooks, etc
Make sure it's obvious to the team when the build is broken.
Report on how long builds stay broken for.
Shame when the duration is longer than an agreed on time.
Add to DoD.
* Continuous Deployment
If this fits your organisational processes.
Or at least be able to deploy at the push of a button or similar
* Agile processes promote sustainable development
We produce working software every Sprint.
To sustain this for years, you must be heavily investing in quality up front.
The team can produce software really fast.
The team can also get the code base into a bad state really fast
Don't let your developers go un-throttled or un-checked
* Measure and reward fast running tests
These are the tests at the bottom of the test triangle.
Slow running tests create frustration and kill developer flow and productivity.
* Measure Cyclomatic Complexity
Add a threshold to keep under to your DoD.
Consider failing the build if the complexity threshold is exceeded.
Once you start down the slippery slope, it's very hard to bring it back.
TDD helps a lot with keeping complexity low.
* Static Code Analysis
Automating as pre-commit git hook.
Getting the simple things right, so we don't have to keep thinking about them.
* Executable specifications
Continue to be useful after the initial release.
This is living documentation that's always up to date.
##############################################################
Overcoming Red Tape http://blog.binarymist.net/2014/04/26/culture-in-the-work-place/
##############################################################
* Establish what the needs are
Taylor your message to suite these needs
* Seek first to understand, then to be understood
Make sure you understand why the existing processes exist
Many business's convoluted processes are actually birthed out of a need rather than just politics.
##############################################################
Overcoming Red Tape
##############################################################
* Relationships
Put yourself in their shoes and understand their perspective.
Give empathy
Convincing the people with credentials gives your idea more clout.
Attitude of gentleness.
* Establishing yourself as an expert
If this is a struggle, enlist other experts to help carry your idea forward.
Do you have other peoples respect? Have you served your time? Have you done the hard yards?
South Africa's Nelson Mandela,
Did the hard yards. twenty-seven years in prison.
That became his authority to solve a major problem in his country.
Involve respected experts on the topic. If the decision makers know of the expert all the better.
* Build Trust with the Decision makers
Build them up not only in front of them, but also behind their back.
The things you say about people behind their backs have a habit of coming back to them.
Make them good things. This will help with winning favour.
* Talk with managers in private
Communicate on their level rather than yours.
Lead the decision maker to the discovery of your idea rather than pushing your idea.
That's his "aha" moment, the realisation.
This way he'll own and run with it.
Attention spans are longer in private than in group settings.
##############################################################
Overcoming Red Tape
##############################################################
* Vocal influential Sceptics
Your worst enemy can be your greatest ally.
Be open to resistance.
Opposition will find every fault in your idea. Use them to hone your idea.
People will realise you are looking at the idea from all angles and will be more likely to accept.
* People base their decisions on emotions then justify with facts
Often we think that if
we have an idea that we're sure is better than the existing way of doing things
and can explain logically why it's better, then people will buy it.
##############################################################
Biggest Morale & Productivity killers
##############################################################
* Undermined Motivation
Studies show that motivation has a larger effect on productivity and quality
than any other factor.
Managers lead from the front / walk the talk.
BlackBay Parcel Force overtime - after counting overtime hours equated to aprx 50c an hour.
* Adding people to Late Project
What can we do to make this go faster?
Do you need more engineers?
Throwing more engineers at a problem usually makes it worse.
The only definite way to get something built faster is to build a smaller thing.
* Noisy, Crowded Offices
Noise everywhere kills deep thought.
Allow your developers to create a space that they love working in.
When I work from home my days are far more productive than
when working for a company that insists on cramming as many workers around you into as small
a space as possible.
* Email
Content is only 7% of communication.
The rest is voice / tone / body language and context.
Takes much longer to craft emails than to just open your mouth.
We have many effective communication tools now. Lets use them.
* Meetings
Just be aware that this is actually not creating software. Just be careful when you hold them.
Often developers work late because it's the only time they don't get interruptions and they have
quiet time to concentrate.
##############################################################
Biggest Morale & Productivity killers
##############################################################
You’re going to need visibility.
Track add-hock requests and interruptions.
In a previous Scrum Team that I was Scrum Master of,
Development Team added another metric to burn down chart.
Every time a developer was interrupted during a Sprint, they would record
the time / reason / who interrupted them, on the burn down chart.
Scrum Team address during the Retrospective,
Why this happened - how to stop it happening every Sprint.
##############################################################
Top Developer Motivators In Order
##############################################################
* Developers love to develop software
The best way to motivate developers is to let them develop.
Provide environment to stimulate focus.
* The Work it self
Variety of Skills
Freedom and expectation to exercise a variety of skills. T shaped developers.
Responsibility, Significance
People who tighten nuts on airplanes will feel that their work is more important and
meaningful than people who tighten nuts on decorative mirrors
Must experience meaning in their work
Task Identity
People care more about their work when they can complete whole and identifiable pieces of
work.
AKA User Stories.
Consumer and Pair Association
Knowing the results of their work and how it affects others
Autonomy
Control over what and how they perform their work.
Self managing teams.
Many managers still need to realise that they can be freed up from a lot of work if they will
just let the Development Team manage their own destiny.
##############################################################
Top Developer Motivators In Order
##############################################################
* Ownership / Buy-in
People work harder to achieve their own goals than someone else's.
The team decides how much it wants to tackle, the developer decides what to tackle.
The schedules developers create are always ambitious.
* Goal Setting
Setting objectives for developers works, but only pick 1 or 2.
More than that and developers loose the focus.
Developers don't respond well to objectives that change daily or are collectively impossible to
meet.
* Opportunities for Growth
Half of what a developer knows in order to do his job today will be out of date in 3 years time.
If not moving forward in this industry, you're moving backwards.
Developers very motivated by learning new things.
Let developers determine how they wish to grow professionally
The best developers will gravitate toward organisations that foster personal growth.
* Personal Life
Top developers like to invest a lot in their own time (experimenting, researching,
teaching others, running events). Let them.
* Technical Leadership
Top developers love passing on their knowledge. This is part of what drives them.
Assign each team member to be technical lead and possibly mentor for a particular domain,
technology and process area.
##############################################################
OWASP
##############################################################
I'm facilitating the OWASP NZ chapter in Christchurch: http://www.meetup.com/OWASP-New-Zealand-Chapter-Christchurch/
Find out what we're up to from the OWASP NZ wiki or the Auckland, Wellington and Christchurch meet-up’s: https://www.owasp.org/index.php/New_Zealand
This month in Christchurch we're hosting a workshop on a vulnerable web application: http://www.meetup.com/OWASP-New-Zealand-Chapter-Christchurch/events/198512052/
##############################################################
BinaryMist
##############################################################
Binary Mist was birthed out of a dissatisfaction with the experiences I had had with how most software shops ran their development teams and treated their clients.
It's my intention to do everything I can to change the industry attitudes I've been dissatisfied with.
binarymist
miyakemito
karawoo
asahihidehiko
line_developers
picardparis
senkin13
mtyk_15
motsuhiro131
gaelvaroquaux
oracle4engineer
junjunjunk
yellowshippo
soudai
holman
sugarenia
ufuk
tanoku
shlominoach
eileencodes
jponch
bermonpainter
thoeni
chriscoyier