PlatformCon2025

After a nice walk though London city, I arrived at the st.Paul’s Convene, a great location for the current size of PlatformCon (I do hope they’ll grow even bigger and more important in the near future).

The conference opened with a nice breakfast, beautifully displayed for all participants

But let's take a flashback to the evening before.

Tuesday 17:00 local time, a meeting started. People from all over the world gathered around a round table to talk about platform engineering and A.I., and the platform as a whole, facilitated by the people from Thoughtworks and PlatformCon.

Honestly every conclusion in this relay is my own, since we kept the discussion open and never drove to any settlement.

We spoke about quite a few topics. 2 Still remain fresh in my mind.

The last one was about how to deal with teams that don’t wish to follow the path set out by the platform teams.

I couldn’t escape the notion this was either a forced hypothesis or in a startup (perhaps a scale-up), the organisation wasn’t that well explained but in my opinion in those lifecycle stadiums of an organisation you don’t need a platform. The next day I would learn from another participant in the same room that some startups definitely need a platform, this is because they extensively work with huge amounts of data and calculations on that data that need to be handled by data scientists.

But, in the first phase of an organisation you generally don’t need a platform, yes you’ll need an environment, be it your favorite cloud provider or your own. It's just, the costs are too high for the startup. The startup needs to go fast , push out new features or products like there’s no tomorrow.

Then later the organisation needs to start thinking about and implementing guardrails. Don’t forget a platform isn’t cheap, let alone the endeavor to build one, but at one point the platform will start to provide a return on investment that makes it a necessity. When that is? I don’t know exactly. But when I talk about one of my own clients idea of growing 200 new personnel each month, it was way overdue. Adding more people to the organisation is definitely a scalability issue of the highest order. Not only for that particular enterprise but also for the market as a whole (the enterprise sucks all the professional out of the market).

The other topic was about A.I.. What’s interesting is that a lot of times it’s the business that tells the developers to use A.I., because why? Don’t know.

Jokes aside, often the idea is to remain competitive. We did get the advice to steer away from the cost competitive argumentation. Go for the question the organisation really needs solved and then cost goals will be achieved because of that.

The main day.

The main stage started with a panel. Very insightful and I want to give you this quote from Richey Zachery: `With platformengineering we’re building developer success teams`.

From that moment onward I proceeded to my first workshop: improving ci/cd pipelines. I didn’t like that one. It felt more like a sales pitch and for that I’d go to the booths in the central area.

Speaking of which, there were some excellent companies at those booths. It was easy to engage with them and not all of them were there to do their sales. I had some pretty good conversations that gave me good ideas for my plans with the platformteam at Cohesion.

Anyway, me leaving the workshop early lead me to a chance meeting the exellent Ana Bogdan. We started to discus the previous evening’s meeting and we came down on some conclusions I came up with. I hope she liked my explanations and arguments because she immediately invited me to another (smaller sized) table discussion session. So how could I decline? The prior evening session gave me already great insights, so would probably give me another batch, right? 

It would require me to miss out on some other session, but hey that’s why we went to this event with a small delegation. Dilyano would have to take those honeurs.

In the meantime before the table session, it was time for lunch, to which I must give great kudos. Well fabricated selection of vegan and non-vegan bites.

Afterwards another session about CDE (cloud development environment) that I don’t like to integrate in an IDP. Those things make me feel like with an earlier attempt in the early 0s. Boy am I glad I’m no longer forced to work with WSAD or Vscode for that matter. I strongly believe the developer experience should augment the developers’ preferred workflow and not restrict it. A developer’s workflow (when one is more experienced) has oftentimes evolved around a set of tools according to the preferences of said developer.

Then the table session started and we discussed topics like difficulties for dataengineering, how to deal with finding the right items/topics to find for an IDP. A nice takeaway is that at some point RFCs no longer work, the scale of the enterprise is just too big and the RFCs deal with matters that is not really the problem that an IDP does need to solve. Does this coincide with when a company grows in the size when an IDP becomes a thing (just a curiosity of mine now)? It is better to do surveys and interviews with your developers to collect the adjustments needed.

And finally the topic on, what kind of persons does one need to search for the development team of an IDP. Something we at Cohesion are trying to find out as well.

I must commend Sam and Ana for creating a healthy environment with such fruitful discussions. And,,, I hope to see more like these in the coming PlatformCons.

Lastly, my encounter with Cornelia Davis from Temporal. She and I spoke on something about measurement on the ci/cd pipelines. What we’re lacking is metrics inside the whole pipeline. Vendors like github and gitlab are great but they don’t give us much insights about the jobs we’re running, and where we could improve on those (this was the stuff I wanted to deal with during the work I prematurely left by another vendor). We should push these vendors to allow for (at least) hooks to examine those metrics.

To end this relay: I loved PlatformCon2025, I hope to see you next year.

Typescript Classes exposed as Interfaces

 Suppose you want to do some Dependency Injection magic, or you just want to use the best practice to talk to interfaces instead of implementations.
For some reason language designers made constructs like `interface` and `class` and gave developers the idea that the construct being defined by the interface keyword is the actual type of interface we should program against. 

Well lets humor me for a bit and deal with this type of pattern. We are gonna define interfaces and type aliases and classes for this exercise, but we're also gonna think about naming.
One thing I really don't like about naming conventions is deterring from the actual semantic meaning of a type. With this I mean all these kind of naming conventions like pre- or post-fixing interfaces with an `I`, or post-fixing concrete classes with `Impl`.

brrrr...

A few months ago I learned that you can have code like this:

export const RiskFactor = {    
    Low: 'low',
    Medium: 'Medium',
    High: 'High',
} as const;

export type RiskFactor = keyof typeof RiskFactor;

As you can see we have both a type alias and a const named as RiskFactor.

This is possible because types live in a different context as the const does.

In fact I rather like this I don't want to name the keys anything different than the const because I will use the same type everywhere interchangeably, so it's kinda bothersome to make the types have a different name.

Now comes the kicker:

when I program against an interface I actually want to use the type defined by the interface so and my class is of that type defined by the interface.

when I export a class `Foo` it will also export the type `Foo`. Remember that types and const live in different contexts so the classname `Foo` can both be used as a type and the identifier of the class construct like this:

export class Foo = {};

const bar: Foo = new Foo();

So when I thought of this, I thought that well this way I can actually use the real word to describe the type I want to use for both the interface (aka type definition) and the class:

export interface Foo {
  name: string;
  help(): string;
};

export class Foo implements Foo {}

To my surprise this works too well???

Why doesn't my code editor tell me to implement the missing properties?

to take this further:

 ...
 const bar = new Foo()
 bar.help() // this now fails with a runtime error not with a compiltime error!!!!

Was I doing something wrong? Cuz this fails immediately:

export interface IFoo {
  name: string;
  help(): string;
};

export class Foo implements IFoo {} // compile time error must implement missing properties name, help from IFoo

This fails as well:

  export type Foo = {
  name: string;
  help(): string;
};

export class Foo implements Foo {}

This fails with the following warnings:

• Duplicate identifier 'Foo'. typescript (2300)
• Class 'Foo' incorrectly implements interface 'Foo'.
  Type 'Foo' is missing the following properties from type 'Foo': name, help typescript (2420)

What I recon from this is that a class exports its definition as an interface and conflicts with type.

The reason I think why the duplicate name of the interface with class does work is due to the typescript feature of interface merging.

When you have 2 or more interfaces with the same name, yes this is allowed in typescript, it merges the definitions of these interfaces into one. I think classes and interfaces behave in the same way and that's why we don't have a compiletime error when using classes and interfaces with the same name.

But now the practical part. 

This doesn't make any sense. I want the compile to direct me with helping me syncing the concrete implementation with the interface(s) it implements, but now typescript suddenly says to me: "Hey dude it's all up to you now, you're back in javascript-land except you aren't cuz interfaces aren't part of the javascript specifications. Well your problem not mine....."

I guess I still have to deal with types that don't mean anything or classes that have a suffix that is just noice.