GeekUp Nottingham


Here are the notes and reading list I took away from Kevin’s talk last night. Excuse that they were written on my iPhone! Kevin was excellent. He has such a rich wealth of knowledge and experience, we spent most of the evening grilling him about various tools and techniques, asking for advice on problems we were having and finding out about really cool and helpful new ways of working. I took many things away from the evening, but mostly a new hunger to improve. Kevin’s repeated message was “Get better and get faster”. I was lucky enough to get a copy of his book “Refactoring in Ruby”, a workbook taking you through a series of code smells and teaching you when and how it is best to refactor.

Thank you very much for coming along Kevin, you were inspirational and thought provoking. You sparked much conversation which I am sure will continue! Kevin’s blog is at – well worth a read!


Theory of constraints

Goal of the organisation flows through into the code, the UAT, deployment. Like manufacturing with a conveyor belt.

With every flow, there is a single place that determines what is produced by the whole flow. Making improvements to anything else is a waste of time. The constraint; the bottleneck.

6 devs fixing bugs, 4 writing them. Constraint is quality.

Developers too slow. Marketing feeding misinformation, devs making things that aren’t required and can’t sell. Constraint is a misunderstanding of market.

6 dice. Each person has a job to do (turn to a number). First pass do in a batch. Took 50s. Looked at process as a whole, improved by turning one, then pass. No one waiting. Down to 17s.

Software Delivery is the same. Releasing a big bundle is bad. Release little and often. Losing money from waiting to release.

Live software: 61% never used 19% rarely used 20% something useful.

Agile stops this.

Batching things up increases spec scope because people are waiting and want to get everything in at once, as will have to wait anyway. Get consumer/Market to decide what they want/need now. Develop in response to actual demand. Pull system, rather than push. Need something more. You finish sooner, because you never get around to doing the stuff that’s not wanted.

Agile is about finding the useful things that the user wants and delivering it to them when they want it.

Agile is about finding the useful things that the user wants and delivering it to them when they want it.

Agile is to be constantly striving to deliver better software, faster.

Meetings – why not just have a chat when you need it?

Patch releases and then bug fix. Get software into maintenance mode asap to get it fixed. Stop calling them issues or bugs or defects, treat them as a stream of enhancements or orders.

Software development is NOT the same as manufacturing. Manufacturing works to a blue print, software devs write the blue print. That’s the source code. The product design. The compilers are the production line.

Software is soft. It lends itself to be built in bits and fleshed out later. Unlike building a bridge.

TDD / BDD is a pull system. Only creating what is required.

Build the right software better.


Don’t have to use a convention like scrum, xp, lean etc. Pick and choose what is good and right for you.

Key process indicators:

  1. Are you making a profit
  2. Do you have delighted customers
  3. How quick is your turn around to get stuff to Market.

Only ever develop software that’s required for Market.

Write it perfectly.

Do this and get the others for free.

Step on graph is cost of release vs cost of not releasing.

Software team is [usually] initially the constraint.

Release quickly and respond to Market feedback.

Ideally striving for the constraint to be waiting for Market demand.

Follow the path of a single request from coming in to getting to market.

Wherever you see piles of stuff waiting, that’s where the constraint is.

Make sure the constrained resource is working 100% on what produces value. Usually that’s enough to shift the constraint.

Adding people is the last thing you should do. Before you add people, get really good.

Batch size is too big?

Employ all of those skills at the same time, rather than forming a production line. Like a swarm, all agree when it is done. Can all agree on stuff that’s absolutely necessary. Analysts are there for the developers to ask questions. Only thing being produced is the source code. All the needs should be driven by writing the source code. Asking questions, working on tests.

Search box. Someone works on look and feel, someone works on the code, someone works on how it should do a search. Show them the ui and they say the expect to type in this, and then to see this.

Where possible, create a crisis to make everyone work together. Have a little retrospective after.

Promiscuous pairing to rapidly share knowledge. The silos are the constraint.

Improve your truck number by knowledge sharing. Easier to share knowledge in people’s heads than teach good tdd and refactoring.

Create opportunities to get feedback.

Read The Goal. About a guy saving a factory.

Getting faster – usually getting good code out as constraint was fixing previous defects.

Map your value stream. Take proof to the business if showing where the work is slowing down.

Recommended Reading:

  1. Refactoring in Ruby (Kevin’s book)
  2. Maverick: about Semco – Brazilian company where teams elect their leaders.
  3. Refactoring Workbook
  4. Integrated Tests are a scam
  5. Growing Object Oriented Software
  6. Hexagonal architecture:

What did you think?

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s