April 29, 2022 @ 9:36 am Posted to jdk, kotlin by Antony Koch

I took a look through the kotlin docs last night. The language looks great! They’ve taken a lot from C#/the pool of good languages and made what looks to be a really cool language to use. Nice and terse, clever additions.

I’ll try to introduce Kotlin in some way at my day job, INSHUR, as we’re a Java shop and I’m hopeful of branching us out into at least a JVM shop.

No comments (click to be first!)

I get a lot of comments

October 28, 2020 @ 9:13 am Posted to spam by Antony Koch

My posts receive several comments per day. However, none of them are from real people. They’re seemingly from Russian spam bots which trawl the web pasting garbage into unwitting comment boxes.

I wonder what their goal is? They always contain a link, which makes sense, but to what? Is it about catching the clicks and compromising people’s browsers? Or is it more of a subversive technique to increase a site’s ranking on Google but having links to it appear across the internet?

If you know, leave a comment. I might see it among the detritus.

No comments (click to be first!)

Work smart, then hard

October 4, 2020 @ 10:12 am Posted to .Net by Antony Koch

Often, I hear friends and colleagues discuss their daily efforts in one of two ways. Either they say hard work gets you to where you want to be, gets the job done, or they tell me to work smart, not hard.

While reflecting on my career and approach, I realised it’s a mix of the two that gets the job done.

Every project I’ve worked on serves as an example of this, eventually. Early hubris, caused by overconfidence in how smart we’re working, typically results in hard work at the project’s end. We didn’t reflect enough during the process to ascertain whether we were still working smart, or if, in fact, we had been working dumb the entire time.

To work smart means to spend as much time as possible planning the shortest route to our short term goal, without compromising our long term goal. In software terms, it means how can we write as little code at possible that both achieves our goal and provides the greatest value towards the codebase and its users while accruing as little technical debt as possible.

To work hard means that once we’ve brainstormed and agreed on how to work smart, we set an ambitious goal requiring hard work from the entire team in order to achieve it.

We then agree regular checkpoints to switch back into smart mode, introspectively validating whether we had worked smart, are still working smart, or need to down tools and completely re-evaluate.

No comments (click to be first!)

Learning about more than code

June 7, 2019 @ 8:59 pm Posted to .Net by Antony Koch

Not every role is an education or exercise in improving ones development abilities. Not every client offers a rich domain in which one can exercise one’s desire to further understand DDD and its associate concepts. But each role does have something to offer if you’re prepared to look in other places.

With my current client, I’ve learned a lot about getting things delivered rather than building something perfect. I’ve finally learned how important documentation can be, not least when it comes to buying yourself more time for delivering value, because you’re not explaining the same thing to person 30, you’re sending them a link. And I’ve truly seen and understood the value of being a mentor and encouraging constant self improvement.

I’ve also had reinforced my opinion that processes and rules only serve as obstacles. That ceremonies should be discarded if they are not adding value. That trusting one’s team to get the job done trumps any other metric or heuristic. Do something that works, then reflect and see if we might make it better. But – and this is a big but – only in discussion with the team. Only with complete buy in from the team. We can agree that we all disagree and try something for a week, then reflect, adapt, and go again.

I have also seen how one person’s desire to continuously improve themselves and those around them can reap huge rewards. Now that person is leaving, I hope to take up the mantle of improving not only me, but all those around me, with regular katas, and a better, deeper engagement with juniors and mids.

No comments (click to be first!)

Leaky Abstractions

October 23, 2018 @ 8:56 am Posted to .Net by Antony Koch

As a software engineer, it’s important to understand what leaky abstractions are, how to spot them, and how to mitigate against them. The term often remains unused by teams, most likely due to gaps in knowledge or training, or for fear of causing offence to colleagues. Understanding its core concepts will help you become a better developer, allowing you to spot potentially poisonous changes that may wreak havoc on your systems in the not-too-distant future. So what does the term mean? How can we spot it? What are some good examples? And when we do spot it in a codebase or architecture diagram, what mitigating actions can we take?

Put simply, a leaky abstraction is any API in your codebase or architecture that reveals too much information about its underlying implementation. One example most of us have seen is an API that returns its fields in all upper case letters, each of which matches the underlying database’s column name. Or an API whose functions and parameters match precisely those of its underlying implementation. Good API design – and by API I mean any interface we use to communicate with a software program, not just an API in the sense of a RESTful service – shields us from the information we don’t need to know. It asks only for that which it needs, and obfuscates unsightly legacy software that might ultimately be serving up its functionality.

When implemented correctly, an abstraction holds up against any and all use cases you can throw against it. If you’ve missed something, it is easier than not to plug in. Writing software to the right level of abstraction, avoiding leaks, is our toughest challenge as developers, but it also offers the greatest rewards. Developers love to be correct, and writing code or a design that holds up to any and all scrutiny feels great. But more than that, it proves that we have understood the problem and have created a solid solution that tackles our problem well enough for now.

An example of a leaky abstraction comes from my current contract, which was a leaky abstraction introduced by a third party into one of the solutions I was working on. We had held meetings regarding service contracts, and had proposed a minimal contract consisting of an entity type and id. . Consequently, the HTTP API would need to do some fetching of resources under the covers, but in doing so it would shield the outside world from needing to know more than the bare minimum. This allowed existing systems in the architecture to consume this service without any need to retrieve additional information in order to call the new API. Unfortunately, the third party didn’t grasp this concept, and decided to introduce several additional fields. Now, it’s at this point I should mention that this was an API over a well know big-name document management platform, the client’s system-of-choice for storing documents. The structure in which the documents were held involved some client metadata, some subsystem data from the client’s CRM system of choice, and one or two other friendly-names from said system. These references, metadata and IDs were now all required as part of the API contract. The rationale was that the API shouldn’t need to fetch additional data from the CRM system ‘because it would be too slow.’ This sounded alarm bells in me. A classic leaky abstraction: The document management system’s underlying file system was bleeding profusely out of their API. I set into motion trying to explain this to the third party. The issue was that any consumer of this API now needed to know a hell of a lot more than it ought to. Want to upload one attachment to a note on a back office incident? You now need to fetch customer details along with the parent hierarchy of IDs relating to the note you’re administering. These changes would permeate throughout the system. I tried to explain that the ‘slow’ call made in the API would now be spread into tens, if not hundreds, of calls from outlying systems that need to fetch the aforementioned data, however the third party – and unfortunately the client – simply did not get the concept. I had failed to appropriately explain the issue and it’s potential for cost. Several weeks later we wound up specifying a new piece of the solution which would cost the client a lot of money to implement, all because the leaky abstraction had not been plugged.

So how can you spot a leaky abstraction? Start with an empty API, and introduce a method or endpoint that has a requirement. Now what’s the smallest amount of information you can introduce that allows you to achieve the APIs goal? Make sure you understand whose job it is to know what information. In the above example, whose job is it to know the underlying folder structure of your document management platform? Is it a website that allows users to add notes to incidents, or the API whose job it is to shield users from such mundanity? Consider why you are building this API in the first place. You are attempting to build something of value; a streamlined way to access a capability. The most streamlined way possible is a clear, concise, and expressive API, with an ability to perform small, discrete tasks to manipulate its internal state while shielding the outside world from how you are manipulating that state.

Perhaps the best question we can ask, again using the example above, is how our API contract look were we to move away from the current document management platform? If we can say that our concepts and naming conventions stand up well, then we have a solid abstraction for document storage within our domain. If we realise we have parameters called parent folder or vnd_doc_sp_search_id, then we have a leaky abstraction.

No comments (click to be first!)

Taking a step back

April 12, 2017 @ 8:00 am Posted to Productivity by Antony Koch

Taking a step back is something we talk about doing, yet rarely find time to. We ponder things in between other thoughts, usually while moving from place to place or standing in the shower. Do these stolen moments offer the most benefit though? What are we missing when we’re lost in thought? Is there a more effective way to think about things?

In Zen Mind, Beginner’s Mind, Shunryu Suzuki says

Or you may say, “This is bad, so I should not do this.” Actually, when you say, “I should not do this,” you are doing not-doing in that moment. So there is no choice for you. When you separate the idea of time and space, you feel as if you have some choice, but actually, you have to do something, or you have to do notdoing. Not-to-do something is doing something

I boil this down to the idea that if I am going to think about something, then let that be the thing that I am doing. Doing something tends to require some kind of output, be it notes, a decision, deferring a decision to a later date, or some other measurable. Passing thoughts in the shower which are soon forgotten have yielded no tangible output. When you are taken out of what you’re currently doing by some thought, if that thought feels important then note down to return to it later, then come back to it.

This is an approach for productivity I have found massively useful. I use EverNote, and create a new note containing a table with two columns. One column is for the current focus of my attention, the other is for thoughts that arise outside the scope of my current focus. I use Egg Timer’s Pomodoro timer to manage my focused efforts, with 25 minutes devoted to items in the left column, then 5 minutes devoted to items in the right column. I do some brainstorming at the start, usually filling the left column with 90% of what I need to do. If anything arises in the mind that cannot fit into the left column, I stick them in the right hand column. If the items cannot be done within the 5 minutes, they get a new note and I tackle that thought process too using pomodoros.

This is taking a step back from my usual mental process of flitting from one thing to another, and instead using targeted attention to get more done in a shorter space of time. Give it a try. Let me know how you get on in the comments.

No comments (click to be first!)

Conversations with Little People

April 11, 2017 @ 9:34 am Posted to Fatherhood by Antony Koch

There is something wonderful about having a complete conversation with one of your children. My eldest son is almost four and a half, meaning he’s now able to hold a brilliant conversation lasting several minutes. This evening’s topic was why George didn’t want to sleep in the top bunk of his bed. We bought bunk beds about 6 weeks ago with some money we came into, money that certainly belonged to the boys, so we opted to get a lovely big wooden bed. George loved being in the top at first, however he’s since developed a fear of darkness and monsters that has meant him sharing the bottom bunk with Charlie.

Tonight I talked to George about it, trying to get to the bottom of his fear. It turns out he was scared of, in this order:

  • Monsters
  • Dinosaurs
  • Ninjas
  • Pirates
  • Polar bears

I discussed each one in order:

  • Not real
  • Extinct
  • More important people to kill
  • Seldom found off the coast of Burgess Hill
  • Isn’t icy today

And he seemed to really take my comments on board. He’s now asleep in his bed, and as ever I am proud and humbled by fatherhood.

No comments (click to be first!)

F# on aspnetcore: Escaping the framework

February 15, 2017 @ 2:24 pm Posted to .Net, dotnetcore, F# by Antony Koch

Mark Seemann has both blogged and talked about escaping the OO .Net Web API framework in order to use a more idiomatic functional style. This is achieved by providing a function per verb to the controller’s constructor, and replacing the IHttpControllerActivator:

type CompositionRoot() =  
    interface IHttpControllerActivator with
        member this.Create(request, controllerDescriptor, controllerType) =
            if controllerType = typeof<HomeController> then
                new HomeController() :> IHttpController
            elif controllerType = typeof<DoesSomethingController> then
                let imp x = x * x
                let c = new DoesSomethingController(imp) :> _
                <| ArgumentException(
                    sprintf "Unknown controller type requested: %O" controllerType,

Then in the startup for your app (global or Startup):


This works great, and I love its honesty. It makes you feel the pain, to quote Greg Young, and in composing tight workflows in your composition root the ‘what’ of your domain is laid bare.

However, this won’t work in aspnetcore because it’s more Mvc and less WebApi, or – to use MS phrasology – more Web and less Http, meaning there’s no IHttpControllerActivator. The fix is simple, and aligned with the terminology: drop the ‘http!’ One instead replaces the IHttpControlleractivator with an IControllerActivator instance inside the aspnetcore DI framework and the same results are achieved:

type CustomControllerActivator() =  
    interface IControllerActivator with
        member this.Create(c : ControllerContext) : obj =
            if c.ActionDescriptor.ControllerTypeInfo.AsType() = 
typeof<DoesSomethingController> then  
                let imp x = x * x
                new DoesSomethingController(imp) |> box
                invalidArg "controllerType" "Cannot find controller"

        member this.Release (c : ControllerContext, ctrl : obj) =   

And in your OWIN startup:

    member this.ConfigureServices (services:IServiceCollection) =
        services.AddSingleton<IControllerActivator>(new CustomControllerActivator()) |> ignore

        services.AddMvc() |> ignore


No comments (click to be first!)

A non-generic AutoFixture Create method

October 24, 2016 @ 8:03 am Posted to .Net by Antony Koch

Sometimes I need to dynamically generate test fixtures, but don’t in the test context have the ability to use generics, instead having only an instance of a Type.

I looked through the AutoFixture code and managed to find a reflection-friendly way to return me an object that can then be changed using Convert.ChangeType where necessary. Here’s the snippet:

typeof(SpecimenFactory).GetMethods().Single(x => x.IsStatic && x.IsGenericMethod && x.Name == "Create" && x.GetParameters().Length == 1 && x.GetParameters().Single().ParameterType == typeof(ISpecimenBuilder)).MakeGenericMethod(type).Invoke(fixture, new [] { fixture });

No comments (click to be first!)

Gauge your code’s adherence to the single responsibility principle

September 26, 2016 @ 7:40 pm Posted to .Net, OO by Antony Koch

During a routine ponderance on software engineering, I was thinking about a conversation recently in which we discussed how and when to copy and paste code. The team agreed that it’s OK to copy code once or twice, and to consider refactoring on the third occasion. This led me to wonder about the size of the code we copy, and how it might indicate adherence to the single responsibility principle.

For the uninitiated reader, the single responsibility principle – one of the first five principles of Object Oriented Programming and Design – can be succinctly summed up as:

“A class should have one reason to change”

The subject of many an interview question, often recited as rote, yet often misunderstood, the core premise can – I think – be understood by just talking about the code block, or class, at hand, in the form of a response to the question: “Tell me all the reasons you might need to edit this class?” Responses such as:

  • “If we want to change the backing store, we have to change this class.”
  • “If we want to change the business rules for persisting, we have to change this class.”
  • “If we want to change the fields used in the response, we have to change this class.”

When recited in one’s mind, are all that are required. And by considering the answers carefully, we can make an informed decision about whether to refactor, or that we’re actually happy with what we have, and are left with the option to change the class easily at a later date. The latter part of this sentence is critical to becoming a better developer, because what we have might be acceptably incomplete, and refactoring might take an inordinate amount of time and fail to offer significant business value to justify the expense.

This said, is copying and pasting code OK? Mark Seemann wrote an excellent blog post on the subject – which I won’t attempt to better – suffice to say I agree, and that it’s OK to copy and paste under a certain set of circumstances. The primary concern is the tradeoff: to suitably generify code requires at most a deeper understanding of the abstractions in play, and at least the ability to introduce dependencies between classes and modules that might not have otherwise been required. A quick copy paste of code that’s unlikely to change is not going to kill anyone. It might introduce an overhead should the code’s underlying understanding change, however volatile concepts do not in the first place represent good candidates for copying and pasting.

Now to wistfully return to the subject at hand – how can we use copying and pasting to judge our code’s adherence to the single responsibility principle? Quite simply: if we can copy only a line or two, then the surrounding code within the method body is perhaps not doing as targeted a job as we might hope. If we can copy entire classes, we can say that we’ve adhered strictly to the core tenets of the single responsibility principle: this class has such a defined person it can be lifted and shifted around the codebase with ease.

This means we can judge any of our code in a couple of ways: answer the question “what reasons does this class have to change?” as well as being honest with ourselves about our ability to copy and paste this code into a different codebase without being refactored.  Would half of the class be thrown away? Would we have to change a bunch of code in order to fit a different persistence model, say copying from a SQL Server backed system to a system backed by Event Store? I think it’s an interesting idea, and definitely one I’m going to keep trying in the coming days.

1 comment