I made a last minute-ish decision to attend CITCON Friday night and Saturday. I don’t normally attend conferences on the weekend, as I prefer to spend time with family. But this was in my neck of the woods - it was in Woking, my side of London - only about 2 hr drive from Bath. And I thought it would be fun to see some people in real life, and possibly learn something. Since it is an open space conference, there is a fair chance that interesting topics turn up, in sessions and outside. I was not disappointed, to say the least. I also got a chance to run a zeroth session on Moldable Development.

Not only was it great to see new people and a bunch I hadn’t seen for years, I also came away with a bunch of learning. Not everything conscious, it is slowly filtering out. I had a headache at the end of the day, and was not the only one. Each slot had at least one session I wanted to go to, and the hallway conversations were also great. Apologies for the somewhat bland writing, a lot of the discussions were confidential in nature.

Spending some of CITCONs zero dollar marketing budget: if you want to be in on the conversations, attend the next one ;-). I didn’t think I would consider travelling for a one and a half day conference, but now I am for next year.

This is a quick-ish write-up, I welcome feedback and questions.

Continuous Improvement in Technology

One of the things I learnt is that CITCON now stands for Continuous Improvement in Technology Conference.

Paul Julius, one of the organisers, just wrote about 20 years of citcon. A good brief summary. It took people a while to get into socio-technical topics from the looks of it. It is great that the conference still has a great blend of topics. This also fed into the hallway track, for which there is also plenty of time. Even at open space conferences, not all topics fit neatly into the schedule.

Sessions

The CITCON wiki has an overview of the sessions with notes. This saves me from writing some of my own.

Teaching the next generation of software engineers - Robert Chatley

session notes including a photo of the board. I particularly liked “Explore Simplicity” (neither easy to teach nor assess) and “Intelligent Disobedience”. I had a note in a similar vein in my hand, but the Intelligent Disobedience added an ethics angle to it that I did not have.

That left me free to explain why I feel Compilers should be in the curriculum (this warrants a separate rant post “why your software engineering program should have a compilers course”, as some universities are dropping this). I just had so much fun doing the intro to compilers course at the University of Twente, and shortly after I started working, it turned out to be very practical.

The course was quite challenging, and had additional levels that you could do for extra credit, which me and my pair did. In hindsight, this removed barriers to considering these things. I never made my own programming language or intricate domain specific languages, but it lowered the barrier to selecting, say, XML parsers, having a feeling for how to integrate these things in to web applications and when to swap one for another (or break it open and make modifications if needed). Having written some parsing code just days before, this seemed like a natural fit. Apparently my ‘practical’ take was unexpected. Which is good. I was glad to hear that Imperial College has compilers in the program still, and hope this inspires to keep it.

A view to a vibe

My session surprisingly had made it to the board, so I did some last minute preparation during Roberts’ session. I showed some visualisations Stephan Eggermonts and I made to support our adventures with typescript generated by claude code. We can fairly reliably generate decent chunks of functionality, but especially single page applications are not easy to do sustainably, so far.

I had a small meeting room filled with “Glamorous toolkit curious” people. They posed great questions, we went through some of the visualisations, It is nice to (finally) have some visuals that I can click through to implementation - seeing the parts and the whole, together.

Since Stephan and I had to do some heavy lifting to get to the first visuals, the code we made has some room for improvement, and I got useful feedback on that too. This was much a trial by fire :-). It was very useful to me, and I hope for the participants as well.

Observability + Experimentation = product signals

Session by Gojko Adzic. It looks like his blog post from bugs to beam covers the theory behind it. This session was an open discussion with an investigation in actual cases. Attend the next conference if you want to know more, because this is about all I can say. I learnt a lot. And it encouraged me to take one product out of stealth sooner rather than later.

I learnt quite a few things about retaining clients for software as a service. And maybe getting new ones in, although that is less obvious.

Spec Driven Development - WTF?

Another one by Gojko Adzic. We tried the ‘new’ spec-kit framework by Microsoft. It was fun to sit around a screen with a few interested people of different backgrounds and see if using a framework to generate prompts is worthwhile. To me it felt like they captured some of the things I did with claude code all the way back in July, but there are better ways now. It seems like a great way to burn a lot of tokens quickly. Our own prompting could have been a bit better, so we could have gotten better results, but still. I am generating a lot less documentation in the process of producing software than I was before - you still have to read at least some of it up front, and when things go sideways (as they did) you have to read more, and there is a lot. At the end of the session, we had no working software, but were through the subscription limit for the next 4 hours.

Gojko wrote a longer piece about the session.

This was still an hour well spent, now I have one thing on my radar less to worry about, and working with these tools in an informal group setting is a lot of fun. None of us was very impressed by the Given/When/Then ‘s produced, but good taste comes from experience, and experience comes from making mistakes. The structured multiple-choice questions were neat, but not enough were generated, so Claude Code went off and chose an old version of NodeJS (I have seen it do this on a regular basis, and prompt to search for recent long term support versions of everything when I do a new architectural spike. I would expect a framework to do this, but it did not generate the appropriate prompt).

AI and Legacy Code

I think this one was hosted by Roland Eschenburg but I am not sure, please correct me if I am wrong. This was a larger group discussion, not limited to AI (which is what you get with a bunch of systemic thinkers in the room). Various tips about using large language models to generate documentation and do smaller refactorings in batch. It felt there was largely consensus on the need to co-create buy in to invest in fast feedback loops (both socio and technical). Some classic DORA metrics also entered the chat - don’t only look at the new shiny, but how long does it take the organisation to rectify a customer problem?

Wrap up

I am still decompressing, it took me a while to write this down. I got some direct inspiration for bootstrapping product, as well as more of a feel from what is going on in the field than I get from (social) media.