Accepting GenAI

My Blacklist of Technologies
When I started out as a Java developer, I wanted to know everything about Java. I wanted to know all libraries and all frameworks. What a silly idea. Clearly Java or software development in general was and still is way too vast to know everything. Beginning 2003, I started ignoring certain technologies. I maintained a black list of topics and libraries, e.g. I decided to ignore all Java web frameworks. Later I ignored EJBs and then I added the whole Spring ecosystem to this list. While I knew these things existed and I had a working knowledge for my day job, I would refuse to study them in my personal free time. There was nothing wrong with these technologies. I did not find them interesting. Using that approach, I successfully skipped all the rage about SOA and other hypes, and I am not looking back. ;-) Explicitly ignoring topics helped me to focus on the things which I liked and considered important.

Scary or Awesome or What
And then ChatGPT came out. (The Wikipedia link is probably unnecessary.) There was an extreme buzz around it, and because of that I wanted to ignore it. A few months later I worked with a group of interns at one of my clients. These young people were enthusiastic about AI - most of them paid for pro versions from their own money - and they encouraged me to look into it. And so I did. And I got frightened. I enjoyed every post that diminished LLMs as stochastic parrots. Let's face it, isn't it weird when a machine can have a conversation with you? I am full of awe, also in a scared way - I am unsure what the right word is to describe my feeling.

Since last year, all of my clients ask for workshops to improve their coding with the use of AI. Code assistants and agents - augmented coding - get better and better. And sometimes the results are surprising. In the end, it is the same if AI works for coding or not - the industry has already decided on its adoption. For some time, I tried to deny it. But after Dave Farley's study about developers using AI, there was more denying it. I had to accept that AI will take over coding. (Dave Farley's video is 12 minutes, without hype, and in the end he gives a clear direction to follow. You should watch it.)

Fear of Obsolescence
Software development is changing quickly, and many of our skills become worthless (says Kent Beck). I read somewhere that "every technological revolution has displaced skills that people spent years mastering" and that "the people that are really skilled, have a lot of room to fall." (says Bryan Seegmiller). Yes, I feel like that. Coding is more than my work (and my fun), it is my identity. I have been playing with code since more than 40 years now. During this time, I have even established habits to use coding for relaxation, and I like exploring topics around code. I do not mean development, I particularly mean coding. I am the Code Cop and I am obsessed with manipulating the textual structure, improving its readability, exploring symmetries, tweaking it, moving it around like clay, and so on. And now all this is going away and it is scaring the hell out of me.

How am I dealing with all of this?
A senior developer from one of my clients, struggling with AI adoption himself, asked me how I am dealing with all of this? I am not, or at least not well. I thought about moving into areas where AI is useless and uncommon (yet?). For example, a study showed that AI is less effective on COBOL and other legacy code. Lovely! I bought a bunch of COBOL courses, and planned to take them. I had several other ideas, too, none of them really helped me till now. The core goal of this post was to list a few resources which really helped me:

• Maybe the first step is accepting the use of GenAI.
  
  
• I highly recommend this podcast with Grady Booch about the third golden age of software engineering. Grady Booch's approach is historical and more systemic. He is calm, with good perspective. It is 80 minutes long, audio-only is enough. This is the first piece that helped me to a more positive attitude.
  
  
• Kent Beck, who probably lost more to the rise of augmented coding than anybody, is lovely. In his conversation with Trisha Gee about Skills Developers Need to Have in an AI Future, they talk about developers losing confidence that they will be able to learn the next set of necessary skills. How true.
  
  
• Embrace Change is the second principle of the Agile Manifesto. While I try to stay clear of processes and am okay whether we use waterfall or Scrum or whatever, I do care about the code, and I favour Embracing Change there, designing in a way that would allow changes. Keeping software soft. Recently I was reminded of that fact by a fellow technical coach. So let's embrace change, even if it is frightening right now.
  
  
• Last month Kent Beck started a new podcast Still Burning where he has honest conversation about what it actually feels like to work in this moment - the fear, the uncertainty, the quiet disorientation of tools changing faster than understanding can follow.. The acknowledgement of these feelings, the disorientation, this is balm for my soul. I have always admired Kent Beck and the podcast setup is so grounded (actual fire, real smoke, Kent is coughing) and humble, it is already a classic.

What Next
These discussions helped me, and I hope they will help you, too. Am I done? I stay critical of using AI, its effects on me, my skills and the world in general. At the same time I try to board the AI train and follow along with the current. There are plenty opportunities to participate in AI experiments right now. Hopefully that will be enough to stay on the topic. My fear of missing out is real, I spend too much time with Generative AI. My wife already urges me to take a break from all this. It is exhausting. Everywhere it is just "AI", "AI", "AI".

Shut up and write a test!

Due to the hype around ChatGPT I wanted to create this text with it. I failed. I tried several versions of different prompts, and also asked the Bing variant, but it failed to create any text I liked. It could not simulate my personal style. I should have to train a model with all my blog posts ... It seemed easier to use with the good old method of writing my texts myself.

Should I Write a Test?
Around ten years ago I stumbled upon a diagram if and when to write a test. This was a repeating question in trainings, when should you write tests? Before or after writing the code? Only when you have time? Only when you feel like it? I loved the diagram because there was only one end state. Whatever the reason or excuse would be, just shut up and write a test! It does not matter if you are tired, or if it is a little change, it should be tested. Such a rule is helpful when you want to adopt Test Driven Development, as there are plenty of excuses why to skip it.


The original diagram was created by Gemma R Cameron, a software engineer and event organiser from Manchester. She was inspired by a similar diagram about skating. Recently, when I was asked again when to test, I wanted to share the diagram and could not find its page. I thought it lost and planned to repost the diagram here. Eventually I discovered Gemma's page again, it had moved from a .me to a WordPress domain. I am glad that the original source is still available. You can find it here.

Java Version
The original version of the diagram was for Ruby, indicated by the use of Automock. What was bad with Automock? It provided some support for automated mocking of Rails application and is dead since 2016. Here I present a slightly modified version for Java, replacing Automock with PowerMock. And I do know what is wrong with PowerMock. It is a powerful mocking tool which uses a custom class loader and bytecode manipulation to enable mocking of static methods, constructors, final classes and methods, private methods and more. It is useful to bring legacy code under test, before seams can be introduced. The bytecode manipulation makes it slow compared to regular mocking. If used often, the whole test suite will run much longer than needed. Further, if code is hard to test, I change its design to make it testable by applying SOLID principles or by creating seams as outlined by Michael Feathers in his WELC book. Using PowerMock for tests does not improve the design. (I am not inherently against PowerMock, it is extremely powerful and as such dangerous. I needed something to replace Automock.)

Download and print the Java version of the Shut up and Write a Test Diagram. The fact that there are versions of this diagram for both Ruby and Java is a testament to the universality of its principle: Shut up and Write a Test! The Code Cop approves, and I am sure your future self will too.

Y U NO TDD

During this year's GeeCON the crew organised an Open Space evening. (An Open Space is a self-organising meeting where the agenda is created by the people attending.) I participated and ran a session on the question why we are not doing Test Driven Development. (Y U No Do TDD?) I am running TDD trainings from time to time and wanted to get more insight where people are stuck with TDD.

Context
As I said, an Open Space is self organising, and only people interested in TDD attended my session. This is a typical problem of communities of practice - only people interested in the topic attend - which results in us living in a bubble. For example long time TDD practitioner Thomas Sundberg and Shirish Padalkar, lead consultant at ThoughtWorks, participated in the discussion. Depending on the background of each individual participant, my original question was understood as:

• Why are you not doing TDD on production work at all?
• Why are you not doing TDD most of the time?
• Why are you not doing TDD all the time?

I collected the reasons not to do TDD during the session which I want to share here. Text inside quotation marks, e.g. "hi" quotes exactly what people said. While the previous three questions are slightly different, the reasons seem to be similar. I grouped the answers. I did not want to contradict or debunk these answers and have to hold back not to do so ;-)

Prototyping
I am "experimenting with something", the "expected outcome is unclear" and "it's only a prototype". Obviously these are valid reasons as Spikes are outside of TDD. These answers usually coming up quickly makes me wonder if they are kind of excuses sometimes. Experimenting with new libraries and APIs is covered further down, so what are we experimenting with? I worked with many developers who would agree that the expected outcome of their current ticket was unclear - because they did not take the time to analyse the story and understand the solution they were supposed to build? Additionally most of our prototypes go to production after all, don't they ;-)

Time Pressure
Another reason - given by some of my clients too - is their need to go fast: "I need to go very fast", there is "no time for that" and I "believe to be faster without it". While they might be wrong in the long term I understand the effects of pressure. One person made it more explicit, while he has no strong deadline, he said "I have a huge backlog, I am stressed". Indeed when I am extremely stressed, I find it hard to maintain a structured approach, especially if a lot of task switching is involved. Besides the needed skill to apply TDD under high load, much discipline is required to endure pressure. In such situations Strong Opinions and Dogma might help.

Missing the Bigger Picture
I am just "writing a script for myself". Maybe there is no need for automated tests when writing a one time script for myself. TDD has a testing aspect - and it has many other aspects like designing software, fast feedback and working incrementally. TDD is not only about testing. Some people miss that or have only partial understanding of the benefits or do not care for these benefits at the moment. The opposite reason is "because I know how the class will look like". Yes TDD is about software design as I said before, and I would like my class to work, too. Some people only want the fast feedback, e.g. using REPL based development and "looking at UI is faster".

Missing Priority on Testing
When starting with TDD, the testing aspect is most visible. After all we have to write a reasonable test first. For teams and organisations with low or missing priority on testing, people are "looking down on testing" and I got answers like "testing is a culture thing", "testing is not a first class activity" and "I am not asked to create a test by my project manager". Indeed it is hard to keep following TDD if it is looked down upon and if there is no time for quality work.

Avoiding Context Switches
There is a certain amount of context switching involved in TDD. Similar to Edward de Bono's Six Thinking Hats, we have different states which we have to be mindful of and which call for different actions. George Dinwiddie created a TDD Hat to show that. Maybe this switching is "not natural for some people". "I don't want to interrupt creative design with verification" and "I prefer staying in building hat and not change to testing hat". Similar one participant said that it is "easy to write code, harder to write tests, so I do it afterwards". I understand and there is certainly an urge to jump into the code and get hacking. I rarely feel that urge and I enjoy pair programming using the Ping Pong style because it enforces the separation of states without any (inner) discussion.

Missing TDD Skills
This is obviously the largest area and there is nothing wrong with not knowing how to apply Test Driven Development: Honest people just say "I can't do it". Many are aware of this problem and seem to be disappointed with existing material and/or look for more material to study TDD: "It is not taught at universities", "there are no good books" and "I am missing real examples". I know from my own experience that TDD is not easy to learn and some people are "scared for life after a bad experience" with it. Now the best way to learn TDD is to have someone show you while pairing with you. Even if there is no pair programming in your workplace, you can still experience it during a Coding Dojo or Coderetreat. Short of that, I recommend Kent's Beck Test Driven Development by Example, which is a short and excellent introduction.

New Language or Library
When discussing TDD and unit testing with a client, he said I "don't know the target technology" and "React is a new technology for us". I had to laugh. To me this sounded like "I got a car and know how to drive forward, but am not able to drive backwards." On the other hand I live at the dead end of a road and I see drivers working really hard to avoid driving backwards. Are they not able to do it? So maybe stopping halfway in the game (of skill acquisition) is natural after all. When working with some new language or working with an unknown API, I specially rely on tests to support me, these are Learning Tests.

It's too hard to test
I agree some things are harder to test than others. "Android is hard to test", "Vaadin is hard to test" and "some libraries are hard to test". (I have not worked with Android or Vaadin, I quote people.) We might need to know more about design to decouple things. This is definitely true for legacy code, as "existing code is usually hard to test". Some people see the root cause, like in "I don't know how to manage boundaries". In such situations we need (to know) more tooling. We definitely "need more tooling to test the UI" as UI is traditionally considered hard to test from a TDD perspective. Still, Steve Freeman and Nat Pryce, authors of Growing Object-Oriented Software Guided by Tests, always start their TDD (outer) loop with an UI test. GOOS is a great book and I recommend reading it if you want to go deeper into TDD.

It's too simple to test
If there are things which are too hard to test, there must also be things which are too simple to test, right? It is "useless to test, it is so simple" and it "makes no sense to test it". Maybe a better description is that it is "unclear what is important to test". From a TDD perspective no such things exist and I guess these reasons arise from the test after process, when looking at each public method and thinking how to test it. Further excessive test isolation, see Solitary vs. Sociable Unit Tests, will cause that.

Barriers to TDD adoption
Here is Matt Wynne's summary of Barriers to TDD adoption from a session during Lean Agile Scotland 2016. I recommend checking out the Twitter thread as Matt added detail discussions on temptation of fast reward, permission and safety to learn, "the egotist" and other reasons not covered by me.


What about test-induced design damage?
Maybe the only real reason not to do TDD is to keep the design integrity of your system. This idea was started back in 2014 by David Heinemeier Hansson, also known as DHH, and led to the whole Is TDD Dead? debate. DHH said that when using TDD code sometimes suffers tremendous design damage to achieve two testing goals: Faster tests and easy-to-mock unit tested controllers and that the design integrity of the system is far more important than being able to test it any particular layer. It is ironic that this never comes up during any group discussion or team interview. Probably because it is an expert level reason. If you followed the debate, DHH knew TDD, he used it for some time and liked it. And then, only then, did he know when not to apply it.