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
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
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
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
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
What do you do when you have a large system that has been built up over many years, services a huge amount of your customers, and you want to improve conversion?
Over the last 18 months, we have worked to rebuild the user interface of trainline so that it appears more modern, whilst still working on top of the codebase that has worked for many years. We transformed our core booking flow UI to go from something that came out of the early 2000s, into a modern responsive website. This all with the help of great frameworks out there like Bootstrap and Knockout, along with Jasmine and CasperJS for our testing. Continue reading
The big selling point of Agile is the fast return on investment it promises. But what excites me most about Agile is its emphasis on people – agility done well injects humanity back into activities which Waterfall has made bureaucratic and devoid of care. In short, care does not scale. Waterfall’s “inhumanity” comes from the command-and-control paradigm. Teams are not empowered to make the best decisions based on their know-how. Instead this is taken out of the hands of the team and decided by others who are not actually going to get their hands dirty.
Agility is equated with empowerment, but how is empowerment achieved? Continue reading