CodeCraftConf by @codecraftuk

CodeCraft logo

The tickets for CodeCraftConf are now on sale. It’s based around the idea of full participation, where every attendee is there to discuss the topics. The format is of guided conversations, which has worked well for sessions in the past, and I’ve included a list of some of my previous sessions using a similar format below for reference. I’ve used the mindmap format for sessions I’ve done in the past so that there is a solid summary that attendees can refer to if they wish, but I have also been involved in sessions at other conferences that were deliberately transient in order to foster honesty and controlled venting, more like a support group for frustrated developers.

I am looking to guide a session at the conference and will be talking to the organisers about the topics,. If you look at the list below, and the conditions on the conference site, it should be clear that this will be a philosophy of code conference rather than a discussion of all the hot technology you don’t know about yet, but really should. (and number 5 will change your life forever).

I realise that holding the conference in a pub, even one as good as Drygate, will challenge the training budgets of some companies, but it looks like a great concept, and I hope the conference takes off. Many thanks to Joe and Gary for bringing this together, and I look forward to meeting everyone there.

What you missed at DDDs

My previous chaired discussion sessions, with mindmaps for reference.

DunDDD 2011 follow-up : What should companies offer when it comes to IT recruitment?

DunDDD 2011 : What do you think about recruitment in the IT industry

DunDDD 2011 : Software Requirements, and How The Web Was Lost

DDD Scotland 2011 : Professional Development and Agile Is Dead

Conference Links

Conference site : http://conf.codecraftuk.org

Tickets : https://ti.to/codecraftconf/summer-2015

Guided Conversations http://code.joejag.com/2015/guided-conversations.html

Advertisement

Agile papercuts

I’ve worked on a few projects and I’ve tried many ways to run them. The agile manifesto is a great starting point, and should be in your bookmarks for quick reference. But when you put it into practice, your first thought is the mistakes you made last time, the lessons you learned, so you can do better this time.

So you look at where things failed, and you add a process around it, maybe one of your own, making taking inspiration from others.

For example, you had a big problem with release management in your last project, and git flow is a process for release management, so you try it on for size.

But the planning decisions about when to deliver features, and how the support and feature releases work together are not changed, because it was a release management problem, not a planning problem. So you add more process.

STOP

Let’s assume you don’t have time for root cause analysis of everything that caused you pain last time. Just assume everything is causing some pain, but for some things the benefit outweighs the cost.

How do you spot what causes more pain than benefit?

Does your process support the people, or sideline them? Is the documentation useful or mothballed as soon as it is delivered? In other words, are you valuing the things on the right more than the things on the left?

As developers, it is a long battle to get over your ego, and the sunk code fallacy, and learn not to be precious about the code you’ve written because the product you’re delivering can always be improved, and if your code is no longer fit for that product, it should be removed. Celebrate the code you no longer have to maintain.

As tech leads, we can be just as precious of our procedures and our practices, but they can be even more painful that the code. They’re harder to refactor, to measure, to test, because people are less predictable than code, but we need to be willing to identify waste, and identify the pain points so that we can address them, and remove practices if necessary. Measure where you can, but don’t be afraid to be as ruthless with your process as you are with your code. Anything that didn’t add value is weighing you down, and even those small papercuts that sung every time are worth removing.

Whatever you think Agile Is, even if you think Agile Is Dead, don’t forget your process is as much a part of the delivery as the code you produce. Own it. Trim it.

The Getting Better Moment

At the stroke of midnight, your code will turn into a pumpkin.

Inspired by The Getting Better Moment – You’ve Been Haacked , this is my story of my first job and a getting better moment.

During my summer break in university, back in 1999, my local council, who part funded my university education, back in the days before student loans, found me a placement at a local charity to develop a CPD database to track the exams their members took every year.

It was an Access database, installed on one machine on the network. With manual backups. It stored the pass/fail data in a set of bit fields in the database, requiring some complex sql to answer the common “who hasn’t done this course yet” mail merge query, it used VBA to parse those SQL queries into a screen full of check boxes to allow users to search.

None of that was my getting better moment though. I went from being a very shy geek at the start of the placement to a slightly less shy geek with a lot of confidence in my code. It was the first thing I’d written that was out in the real world and I was proud of it.

Until the first work day of 2000, when it stopped working. Despite the initial suspicions of the customer, it wasn’t a y2k bug. There was a bug in the end of year routine. What it was meant to do was create an empty exam results table for the new year, then rewrite the rest of the system to point to that table do that all the queries, screens and reports were up to date. It failed because it wasn’t properly tested. And I spent a whole day in their office, feeling sheepish, rebuilding the queries, screens and reports by hand to fix the mess.

But that wasn’t my big learning moment. That came exactly a year later, with another call, and another broken database. A lot of pressure now, trying to remember a fix from 12 months before on 18 month old code. It took longer than the first time, but I spent some time afterwards documenting the fix, testing the end of year rollover, and simplifying the code so I was capable of debugging it.

Luckily the customer was reasonably happy, as they didn’t run many exams in the first week of the year, and they understood you don’t get perfect solutions when you pay student placement wages, but I have tried hard since then to keep the customer happy and keep bugs that are fixed, fixed. All software has bugs in it, it’s how you deal with them, and the customer, that separates a professional from a beginner. The experience set me on the path towards TDD, open and honest communication, and not wanting to pick up support calls out of hours, which is a great motivator of quality. If you can lie on a beach, knowing you won’t get called because your code just broke, you’re doing it right.

What’s your getting better story?

Agile Is…

If you’re not agile…

For those of you who came to this blog for my rant on Agile Is Dead, I’d like to recommend these posts from Nathan Gloyn if you want something more actionable.

• Agile isn’t : http://designcoderelease.blogspot.co.uk/2015/06/agile-isnt.html
• Agile is : http://designcoderelease.blogspot.co.uk/2015/06/agile-is.html
• What does a good agile environment give you : http://designcoderelease.blogspot.co.uk/2015/06/what-does-good-agile-environment-give.html

I can’t say my day job is all agile, but I try and nudge us down the continuum where I can. Process is all about supporting people, rather than vice versa, but documentation it’s one area that’s harder to go agile with. All my recent projects have a set of must have requirements defined as legislation by politicians in parliament, and it is often clear that implementation is not a primary concern. Legislation appears designed for ambiguity, with the expectation that courts or ministers will be able to clarify the grey areas. Which means more documentation.

Only one project I have worked on recently allowed us to have some influence on the legislation, because we were working directly with the government department involved, and the chief civil servants involved in the legislation were in our workshops, and the project started before the legislation was complete. It’s a strange, and not entirely unpleasant, feeling getting answers to outstanding questions from a politician reading amendments in parliament.