Matt Kimber (Page 4)

Galápagos Syndrome

Galápagos syndrome [https://en.wikipedia.org/wiki/Gal%C3%A1pagos_syndrome] is the phenomenon of something becoming so specifically adapted to its environment that it cannot survive anywhere else. Giant tortoises are the obvious, and name-giving example, but it also encompasses things like malaise-era American cars - vehicles hyper-specialised to

Changing platforms

I've sunsetted the free Azure site this blog used to live on and moved to dedicated hardware. In the process I've decided to move from BlogEngine.net to Ghost. This may seem arbitrary but it reflects a lot where my journey as a software developer is leading. I'm done with

Kubernetes pods stuck in pending? Check your scheduler is up and running!

Something that I spend a lot of my time working on at the moment is containerising workloads. We run a lot of this stuff in AWS, which has some nice orchestration facilities as a part of ECS - but I've been looking at a way to have this same sort

organisations

Updating the Joel Test for the modern world

Hands up who remembers the Joel Test [http://www.joelonsoftware.com/articles/fog0000000043.html]? It might take some remembering, because it's a shade over 15 years old now - pre-dating the Agile Manifesto. For those of you who don't, Joel's writing on software was some of the earliest, "actually, this

Featured

Why you're (probably) doing Kanban wrong

Kanban has been an accepted way of organising software maintenance for a long time, but we're now seeing a lot of companies embrace it as the new hotness for running feature development as well. There's a lot to like; you can effectively prevent your team from working on ten different

Terraform - Infrastructure as code

We've been looking at how to effectively manage our cloud empire lately. While spinning up instances, balancers and clusters in the AWS web interface is easy, sooner or later you run into the same problem as traditional servers where you don't know how any given box is configured or why

agile

Avoiding nightmare releases

Something I've seen a lot of supposedly Agile teams fail with is releases at the end of a project. Everything up to that point ticks along nicely, but the final sprint is a monstrous combination of time extensions, shifting scope, last-minute changes and unexpected problems. I've seen all sorts of

architecture

It's a web server, not a task multiplexer

I spent an exciting part of today debugging a service which was failing in production, but not in any demo, UAT or dev installations. In doing so, I discovered one of those architectures which requires me to go and make a cup of tea in order to distract my hands

The Rules

I missed an interesting discussion today (my fault, I had work to do), but the subject merits a post. The gist is that with all the advice on SOLID principles, TDD, BDD, enough "seminal works" on coding style to fill up a small library and whatever house rules an individual

architecture

Pass-through objects

Take a look at this class: public class ThingHandler : IThingHandler { private readonly IUnderlyingThingHandler _underlyingThingHandler; public ThingHandler(IUnderlyingThingHandler underlyingThingHandler) { _underlyingThingHandler = underlyingThingHandler; } public Thing GetThing(int parameter) { return _underlyingThingHandler.GetThing(parameter); } } I've seen variants of this everywhere I've worked. Sometimes it doesn't have the dependency injected, sometimes it catches and imm

development

ECS and containers with long bootstrap times

I've been playing with Amazon's EC2 container service [http://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html] (ECS) recently, and it's proving an impressive piece of kit. It's not quite one-click, but as a set of tools to automate putting Docker containers on machine instances, registering them with load

development

Why you shouldn't use InProc session state

By default, ASP.net ships with a couple of inbuilt session state providers. These are responsible for making sure that when you access HttpContext.Current.Session, you get back whatever you stored in it last. The default, and by far the easiest to work with, is something called InProc. This

architecture

Architecture Envy

My comment on a failed project: "The architecture looks like someone spent an afternoon throwing darts at the index page of Gang of Four". There's a serious point buried in this, which is that most of us will spend at least some of our time working on projects that neither

teams

JFDI Deployment

One of the things which small and startup companies often do so much better than large, established ones is encapsulated in this four-letter acronym: JFDI. Just Fearlessly Do It. (You can exchange your own 'F' if you prefer). The reason you JFDI so much as a small company is because

development

Repeating yourself

I think all good developers are aware of the basic axiom of "don't repeat yourself" - avoiding writing similar code over and over by making the effort to design and refactor what you've got so it handles all of your use cases. Where we're not so good is being able

tdd

The value of tests

A couple of things this week reminded me how important it is to have a decent set of tests for your code. The first came out of me being asked to add a piece of functionality to an application. It turned out that said functionality had always existed, but since

development

No (more) heroes

A good development team has no heroes. There are three common "heroic" feats in software development: * Hacking in features in a fraction of the time it should have taken. * Pulling all-night hacking sessions to get a delayed project out the door. * Fixing a hack that exploded in production and took

career

Career advice to graduates

My career advice to graduates is simple: get technical, and get good at it. The world of development is changing. To get my first few programming jobs, I had to tell someone where I expected to be in five years, what my greatest weakness was and explain how many petrol

planning

Necessary and sufficient

One of the teams I work with is about midway through a project, and we're starting to take stock of what's gone well and what we've learnt that we could do better next time. (This kind of reflection is normal and healthy in an agile environment. It's when you don't

Some common .net SSL connection problems

There are a couple of surprises you can encounter on Windows/.net when your web application makes an SSL connection to a SOAP service. The typical symptom is that you can connect fine using SoapUI or a similar testing tool, but the web application itself fails with a fairly generic

teams

Why startups are fun

Working for a good tech startup is fun. There's a lot of energy, a certain amount of chaos, a huge amount of work produced and a general atmosphere of people enjoying themselves at work. It's something a lot of companies struggle to hold on to as they grow, and it's

teams

Ownership: Technical Debt

Hands up who didn't see this one coming? Technical debt is one of those strangely taboo subjects in the development world. Everybody has it, but nobody wants to talk about it when it comes to sprint retrospective time. Which is strange, as one of the first things any group of

architecture

Ownership: Architecture

I talked yesterday about what happens when development teams lose ownership of the software requirements. In that, I mentioned that teams need to own their architecture and technology stack. Surely this is so self-evident it barely needs mentioning? Well, not quite. In fact, it's incredibly common for developers to be

Ownership: Requirements

One of the key indicators of a successful tech company is that the development team have a lot of ownership. It's something that Scrum requires, by the way - but as I've noted previously the state of agile development practice across the industry isn't great. Ownership is a difficult idea,

The best architecture planning tool

I'm going to reveal a trade secret. The most effective, easy-to-use tool for designing software architecture that I've ever used: Screenshot showing some of the many features of the product including annotations, fast refactoring, and an almost infinite library of arrows, boxes and callouts instantly accessible It might seem low-tech