The AI puppet dance
The AI hype wave is washing over us, fueled by advances in generative AI tools. It's a mixture of grandiose claims, speculations, euphoria and panic. Everyone wants to demonstrate that they are on board the AI train choo-chooing towards the future, that they're not getting left behind. The rhetoric will have us act, not think - there is no time! Is that true? It's a paradox that we are supposed to meet artificial intelligence with our own intelligence turned off. If it's true that AI will "change everything", surely we need every ounce of human intelligence - as well as compassion, wisdom and humanity - we can muster! And what if it turns out to be false? At what cost do we participate in this dance?
Socio-technical API patterns
When we connect software systems through APIs, we also connect the people who work on those systems and their contexts. It is a social process that is more important for the fate of the API than the technologies involved in building it. In this talk I will lay out the socio-technical landscape for APIs by discussing factors that influence the relationship between API providers and consumers, such as the alignment (or misalignment) of goals, the mode of communication, the design process, typical points of contention, etc. With this background, I will discuss a number of recurring patterns I have encountered in my career, including the Millstone, the Mountain (or the Volcano), the Rapids (with or without Beaver Dams), and the Sock Puppet. Identifying such patterns is important to better understand and address common challenges, so that we can achieve better outcomes for our APIs.
Modelling vs Reality
To make sense of the world, we rely on our brains' capability to form fictions that we call "categories" of things and experiences. This capability is both automatic and hidden: we can't avoid doing it, yet we don't know exactly how we do it. We know that differences and similarities play a role, but how? When we try to be more deliberate about the process, for instance because we want to write software based on our categories, we call it modelling. In the process, we tend to replace our intuitive but ill-defined common-sense categories with more precise technical categories. But precision comes at a cost. In this talk, we'll look at different perspectives on categorization, see that nothing remains the same for long, and that edge cases are just regular cases that got unlucky.
Beyond the terrarium?
There is a mismatch between our ideals for digital product development and the reality of it. We speak of bridging the gap between business and IT, taking a seat at the table, direct customer involvement, self-organizing teams having the means, skills and mandate to own business outcomes. This is the ideal of the stories told on podcasts and in best-selling books. But the reality is this: Software development teams live inside a protective terrarium, sheltered from the chaotic, toxic environment of the rest of the business. Teams communicate with the environment through the means of a messenger, who bridges the world of business and development, translating needs and concerns. The business tries to control and optimize the conditions inside the terrarium, avoiding too much and too little of anything (causes laziness and demotivation, respectively), asking if the busy silkworms are feeling safe and thriving, if they are suffering from cognitive overload, all the while applying a mild pressure to produce, perhaps a little faster, a little more this time, this sprint. The levers to control the conditions inside the terrarium reside on the outside, which means that the teams can only pull them indirectly, by sending messages via the messenger. Then, the team must wait for divine intervention from a powerful being living in the harsh environment outside the terrarium. Perhaps their prayers will be answered, if not now, then soon? Eventually? This sounds pretty bad, but this model has both strengths and weaknesses. There are obviously reasons why this model has become so prevalent. What forces and constraints have produced this model? Are we still bound by them? Is it the best we can do? What does that mean for the stories we tell? Should we tell different stories instead? Or should we try to change reality? What would it take for us to break down the terrarium and expose our development teams to the full extent of reality? Are we willing to do that? Is it worth the cost?
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top