Be Afraid

Be afraid.

It’s OK. You are allowed to be afraid. No need to ask permission for it. We’ll worship the gods of Agile, and we won’t even have to work and push and move to do things, we can just point at our collective fear and say “we didn’t have permission”. We won’t feel right about it, but that’s OK. It’s not like we’ll tell anyone. Be so afraid you don’t care, be afraid to move jobs, be a fearful cog in a fearful machine, ground into meek submission. Continue reading

I’m a Database Developer, this is what I think about data

You are sitting at your screen reading a blog about the death of monolithic databases:

comicshopguy

Monolithic databases are so 80s, inflexible, they are an obstacle to change. Referential integrity stops us implementing service orientated architecture, and they cannot be harmonised with continuous delivery”.

 

And you agree.

Well, you may be right, sometimes, but I assume you don’t agree with the following two statements: Continue reading

Foreign keys – don’t go there.

You’re probably a medium-to-large-sized company, you run a medium-to-large application. You apply all the industry best practices, using micro-/plain-old-service architecture, compartmentalise your system into nice tidy chunks. As they usually do, your DB admin doesn’t like to maintain multiple databases and so you’ve been restricted to run everything under one fairly large database.

One fine day, you decided your data is important, it needs integrity. You decided the best thing to do is to introduce foreign keys.

 

You may have just made a big architectural mistake

Continue reading

Keeping New Relic new

Paul, @pkiddie wrote a great blog about how we’ve made our customers happier – and engineers using New Relic. We were also given the opportunity to present some of these ideas at a recent New Relic User Group meetup in London.

New Relic London Meetup May 2015 trainline slides.

Now with New Relic ticking along nicely, and dashboards all up next to our product teams so they can see the error rate, revenue and response times. We wanted to make sure we kept up to date with the latest features from New Relic. (Those updates have been arriving up to twice a month for the .Net APM agent we’re using.) As a cloud hosted platform, New Relic is continuously updated and improved, and we want to get the most out of our investment in it by keeping up to date with each release. It also makes our product teams happy when they get to play around with the latest new features. Continue reading

I want you to give up programming

We’re programmers, you and I.  We are time-served, battle-hardened veterans.  We have honed our objects, learned our digital ropes, intoned the Laws of Liskov and Uncle Bob, and we’re now pretty good at what we do.

And now I want you to stop what you’re doing.  I want you to give up all that programming that you know and love, and I want you to do something else. Continue reading

Pushing back – lean thinking

Sumo Konishiki by Raymond Kennedy 2009

Photo by Raymond Kennedy 2009

It’s a very hard thing, telling your CTO you think he or she is wrong – but it’s worth it!

Let me tell you a little story – of a time I told someone he was wrong, did the right thing, and where we are now.

Once upon a time, there was a developer called Alex. He was quite short, not terribly adventurous as developers go, but capable. Here’s Alex, developing a little feature to go on the website. Hello Alex. Alex is happy, because the feature he’s developing is rather useful, and will earn the company money – we know because this feature was tested first, and it did these things when we tested it. Alex likes this. Alex likes that it’s good all round and he especially likes that we already know that.

But what’s this? Alex’s CTO has sent him an e-mail, with some changes to the component that haven’t been tested, whether or not they are the right thing. See Alex get sad. See Alex cry. See Alex think. Think, Alex, think. “How can we do this?” thinks Alex. Oh Alex. Poor Alex. See Alex go home, dejected. Continue reading

How to manage change and build antifragile software

The Life of a Software Engineer

Image from bonkersworld.net

When building a software system the biggest problem we face is change. Requirements change, technologies change, traffic on our web application changes, everything changes and our software that was perfect just a moment ago, now is broken and no longer suitable for our purpose. Continue reading