What developers want from AI…

https://dl.acm.org/doi/10.1145/3690928

In this time just before X-Mas, I sat down to read the latest issue of the Communications of the ACM. There are a few very interesting articles there, starting from a piece from Moshe Verdi on the concept of theoretical computer science, through an interesting piece of text on artificial AI to a very interesting article that I’m writing about now.

The starting point of this article is the fact that we, software engineers, are taught that we should talk to our customers, discover requirements together with them and validate our products together with them. At the same time, we design AI Engineering software without this in mind. A lot of start-ups (I will not mention any, but there are many) rush into providing tools that use LLMs to support software development tasks such as programming. However, we do not really know what the developers want.

In this article, they present a survey of almost 1,000 developers on what they want. Guess what – programming is NOT in the top three on this list. Testing, debugging, documentation or code analysis are the top requests. The developers enjoy creating code, what they do not enjoy is finding bugs or testing the software – it takes time and is not extremely productive. Yes, it feels great what you find you bug and yes, it feels great when the tests finally pass, but it feels even greater when you work on new feature or requirement.

We follow the same principle in Software Center. When creating new tools, we always asks the companies what they really need and how they need it. Now, we work on improving the process of debugging and defect analysis in CI/CD. We started by a survey. You can find it here. Please register if you want to see the results of the survey – and contribute!

With this, I would like to wish you all a Merry Christmas and a Happy New Year. Let’s make 2025 even better than 2024!

Nexus… book review

Nexus : en kort historik över informationsnätverk från stenåldern till AI : Harari, Yuval Noah, Retzlaff, Joachim: Amazon.se: Böcker

I’m a big fan of Yuval Noah Harari’s work. A professor who can write books like no one else, one of my role models. I’ve read Sapiens, Homo Deus and 21 Lessons… now it was time for Nexus.

The book is about information networks and AI. Well, mostly about the information networks and storytelling. AI is there, but not as much as I wanted to see. Not to complain, Harari is a humanist and social scientists, not a software engineer or computer scientists.

The book discusses what information really is and how it evolves over time. It focuses on storytelling and providing meaning for the data and the information. It helps us to understand the power of stories and the power of information – one could say that the “pen is mightier than the sword”, and this book delivers on that.

I recommend this as a reading over X-Mas, as the holidays are coming.

Quantum software engineering

IEEE Xplore Full-Text PDF:

Quantum computing has been around for a while now. It’s been primarily a playground for physicists and computer scientists close to mathematics. The major issue was that the error rates and instability of the quantum bits prevented us from using this kind of paradigm on a larger scale (at least how I understand it).

Now, it seems that we are getting close to commercialization of this approach. Several companies are developing quantum chips that will allows us to use more of this technology in more fields.

The paper that I want to bring up today discusses what kind of challenges we, software engineers, can solve in quantum computing – and it is not programming. We need to work more on requirements, architecture, reuse of software and quality of it. So, basically the typical software engineering aspects.

BTW: On the 12th of December, we have a workshop on Quantum Computing in Software center – Reporting workshop: The end of Software Engineering – as we know it – Software Center

When it gets too much or Revenge of the Tipping point…

BIld av Katja S. Verhoeven från Pixabay

https://www.bokus.com/bok/9780316575805/revenge-of-the-tipping-point-overstories-superspreaders-and-the-rise-of-social-engineering/?utm_campaign=Performance%20Max%20%7C%20English%20%7C%20Rooth&gad_source=1&gclid=Cj0KCQiAuou6BhDhARIsAIfgrn4spmK1A21PF2Luov0HXzMwMFMsTcJKUSsvnIH5UEfxDs_lBz3TOUMaAuLEEALw_wcB

I’ve just finished reading this great book about the way in which the tipping point tips to the wrong side. It’s mostly about the law of “The large effect of the few” as Malcolm Gladwell puts it. In short, this law means that in certain situations, it’s the minority that is responsible for large effects. For example, the minority of old, badly maintained cars that contribute to to over 55% of pollution in one of the US cities. It’s about when one person, a superspreader, ends up in very specific conditions that allow this person to spread the contagion of the COVID virus at the beginning of the pandemic.

Now, we see that in software engineering a lot when we look at the tooling that we use. Let’s take the CI/CD tool Jenkins as an example. It is one of many different tools that were on the market at that time. It was not even the major one, but it was a sibling to a professional tool that was maintained by Oracle (if I recall correctly). Yet, it became very popular and the other tools did not. Since they were siblings, they were not worse, not better either; maybe a little different. What made it tip was the adoption of this tool in the community. A few superspreaders started to use it and discovered how good the tool is for automation of CI/CD tasks.

I see the same parallel to AI today. What was it that tipped the use of AI? IMHO it was a few things:

  1. Google’s LSTM use in Search – since there was a commercial value, it made sense to adopt it. Commercial adoption means business value, improvement and management focus (funding).
  2. Big data – after almost a decade of talking about big data, collecting it and indexing it, we were ready to provide the data-hungry modules with the data they needed to do something useful.
  3. HuggingFace – our ability to share models and use them without requirements on costly GPUs and large (and good) datasets.
  4. Access to competence – since we have so many skilled computer scientists and software engineers, it was easy to get hold of the competence needed to turn ideas into products. Google’s Deepmind is a perfect example of it. People behind it got the Nobel Prize.

Well, the rest is history as they say…. But, what will the next invention on the verge of the tipping point be?

Never eat alone, or else….

Image by Silviu on the street from Pixabay

Never Eat Alone: Keith Tahl Ferrazzi Raz: 9780241004951: Amazon.com: Books

In academia, the motto is “publish or perish”, with the emphasis on publishing. It’s for a good reason – we, academics, scholars, researchers, exist in a complex network of dependencies. We need others to get inspiration, understanding and when we get stuck.

If you look at the nobel prize winners, most of them work together. Listening to them I get an impression that you cannot become great by sitting in your own room and hatching ideas. But, at the same time, we are often introverts, at least I am.

This book is a great example of how we can build our networks and make meaningful connections. It helped me to realize how to be good at meaningful networking, not the one where you focus on meeting as many people as possible or as important people as possible. No, it’s about how to meet all kinds of people and how to learn from them. It’s about how to identify even a single item of information that you can use in your own work and for your own benefit.

I recommend this as a reading for one of those dark, autumn evenings that are inevitable coming now….

Materials that shape the world (of computing)

Material World: A Substantial Story of Our Past and Future: Ed Conway: 9780753559178: Amazon.com: Books

As a software engineer, I take hardware for granted. Moore’s law has taught me that all kind of computing power grows. My experience has taught me that all computing power is then consumed by frameworks, clouds and eventually is not enough.

This great book shades a really interesting light on the way in which materials like Lithium and Silicon shape our society. We think that TSMC is one of the isolated companies that excelled in chip-making. The reality is that this company is great, but it is also only one in a long chain of suppliers of the chip industry. We learn that the sand which is used to make chips comes from the US, not from Taiwan. We learn that the lithium used in our batteries comes often from the Andes, Chile, not from China. We also learn that the ONLY way for the humanity to progress is to collaborate cross-nations. If we don’t do that, no single country in the world has the machinery, the know-how and the competence to develop our modern technology.

It is in a series of great readings for software engineers when they start their studies today.

How innovations spread…

The Innovators: How a Group of Hackers, Geniuses, and Geeks Created the Digital Revolution: Isaacson, Walter: 9781476708706: Amazon.com: Books

Although this book is a bit dated – in the sense when we call everything that is pre-pandemic as dated – it is a great reading. It takes us on a journey of inventions in Silicon Valley, although it starts with Ada Byron and her work on computing machines.

I recommend this book because it goes against established theories in academia about innovations – that we innovate individually or in teams. Instead, it takes us on the journey of connections, research and innovation building on one another. It tells a great story how world’s technology evolves by taking one innovation and making another one. It is a story of global collaborations and how these collaborations are entangled with one another and support one another.

If it was up to me, this would be a mandatory reading for all new students of the university software engineering programs.

How to create a tribe…

Conspiracy: A History of Boll*cks Theories, and How Not to Fall for Them: Phillips, Tom, Elledge, Jonn: 9781472283405: Amazon.com: Books

During the holidays, I’ve had some time to read books outside of software engineering. This one caught my attention, not because I like conspiracy theories, but mostly because I got interested in how theories actually spread.

Now, while this book is about conspiracies, don’t get me wrong, it is also about creating communities and making things spread. Whether this is a conspiracy or maybe just a normal culture, it is interesting to read.

Anyways, if you have some time on your hands, instead of scrolling Instagram or Facebook feeds, take a look at this book. I guarantee that it will provide even more fun.

How to improve the code reviews

https://dl.acm.org/doi/pdf/10.1145/3660806

I have written a lot about code reviews. Not because this is my favourite activity, but because I think that there is a need for improvement there. Reading others’ code is not as fun as we may think and therefore making it a bit more interesting is much desirable.

This paper caught my attention because of the practical focus of it. In particular, the abstract caught my attention – they claim that changing the order of files presented for review makes a lot of difference. Up to 23% more comments are written when the files are arranged in the right order. Not only that, the quality of the comments seems to increase too. More tips:

  1. Re-order Files Based on Hot-Spot Prediction: The study found that reordering the files changed by a patch to prioritize hot-spots—files that are likely to require comments or revisions—improves the quality of code reviews. Implementing a system that automatically reorders files based on predicted hot-spots could make the review process more efficient, as it leads to more targeted comments and a better focus on critical areas.
  2. Focus on Size-Based Features: The study highlighted that size-based features (like the number of lines added or removed) are the most important when predicting review activities. Emphasizing these features when prioritizing files or creating models for review could further streamline the process.
  3. Utilize Large Language Models (LLMs): LLMs, such as those used for encoding text, have shown potential in capturing the essence of code changes more effectively than simpler models like Bag-of-Words. Incorporating LLMs into the review tools could improve the detection of complex or nuanced issues in the code.
  4. Automate Hot-Spot Detection and Highlighting: The positive impact of automatically identifying and prioritizing hot-spots suggests that integrating such automation into existing code review tools could significantly enhance the efficiency and effectiveness of the review process.

Sounds like this is one of the examples where we can see the large benefits of using LLMs in code reviews. I hope that this will make it into more companies than Ubisoft (partner on that paper).

I’ve asked ChatGPT to provide me an example of how to create such a hotspot model and it seems that this can be implemented in practice very easily. I will not paste it here, but please try for yourself.