00:00:00.240
Hello everyone! I'm excited to be back in Ancient City. I can't help but quote the ancient part of the city because there are actually some JavaScript frameworks that are older than this city itself. This is the second time I've come back here. You could say it's like series one, episode two. I'm really grateful to Hashrocket for inviting me back. I was actually surprised that they did, because I'm pretty sure some people from Hashrocket think I'm Ben Orenstein. It’s probably a bad time to find out that I’m not! Anyway, I did have some demands. I'm a bit of a big deal, traveling the world and sharing thoughts, but I don’t have too many demands. One of my requests is that I have an entry theme tune, which obviously didn’t happen, so you had one job there!
00:00:24.560
Another demand is that I have a bath full of blue M&Ms. I don't know if any of you have ever played the game 'Winners don’t use [__]'. I’m from London, England. Nobody in England is quite like me; we’re much more subdued. There’s a story to go with this picture I took at Christmas. I woke someone up on a train and asked him to [__] off because he was doing yoga! Speaking of 'douche', we had an eclipse. I don’t know if you guys experienced it too. Here’s a public service announcement: don’t stare into an eclipse, you will die. There’s only one thing worse than staring at an eclipse: staring at Visual Studio. Go away, evil one!
00:01:11.200
I work for the Money Advice Service in London. Since the last time you saw me, I’ve been quite busy. I started my own company, and I took my time with it. I agonized over the name and went through all sorts of permutations. Then I just flipped a table and called it Ben Lovell Limited. Funny story, when I incorporated the company, I actually spelled my name wrong. Instead of Ben, I accidentally called it Ban Lovell Limited, but thankfully, the solicitor spotted it and corrected it at the last minute. My lawyers are watching, so don’t take my name. My strapline is 'Giving no [__] since 2014'. That’s on all our headed note paper and it works well for business.
00:02:50.080
Thanks again for inviting me back. I hope you enjoy the talk; it’s not just the intro! So, Rails rocks! You all agree that Rails is really good for getting up and running fast, and we’re all here because of that reason. But I'm going to explain to you via the method of science. You saw Hampton’s graphs earlier; Hampton’s graphs haven’t got [__] on mine. Check me out! So this is going to require some explanation. I didn’t bring my lab coat, and I don’t have my monocle, but bear with me.
00:03:05.599
On this axis, we have time, and on the other axis, we have hate. I’m going to explain that as time goes on, you start to hate yourself with Rails. At the beginning, you are on fire; you are full unicorn and slinging features like there’s no tomorrow. But as time passes, things start to get tricky. The cost of change and the rate of change begins to hurt you. The test suite starts to slow down, and all of these factors add up. Eventually, you reach a point on the hate scale where you find yourself thinking, 'I made a wrong decision somewhere'. Maybe I should have stuck with JavaScript or anything but this!
00:05:02.639
Then, you reach a point where you just flip the table and cease to care anymore. You’re not even sorry. The expression captures so much emotion; it’s just a tide of feelings! If you want to avoid me in the future, block me on Twitter, GitHub, and IRC! We've also been beta testing this new form of communication called 'speaking'. This is how it works: you come up to me, open your mouth, and talk to me; I open my mouth and talk back. Let’s try it later; I find it helps if you have a beer in your hand.
00:05:28.000
To be honest, I really suck at software. I super suck! Here are some commits I made the other day that I’m going to share with you for your amusement: just pissing in the wind! This is a [__] bomb. I coined this phrase—it’s my eponymous Law of Software. If you want to sound clever, just talk about autonomous laws of software. My one is: 'Programming is like skipping merrily between car crashes.' It hasn’t really caught on yet, but I say it to myself regularly.
00:05:43.440
Why do software projects go wrong? Especially Rails projects? Well, the ones I work on are obvious. But for you guys, what are the symptoms of projects that go awry? One evident point in London right now is the nature of the workforce. We have a lot of contract and freelance staff who move around frequently. You never really get that sense of ownership when you look at a codebase; it’s evident that many different hands and minds contributed, some stronger than others. Another problem is the attitude towards just making it work rather than making it right or fast. Too often, most of us just make it and then move on to our next invoice.
00:06:33.760
Time pressures also come into play. I have two young children, and they used to ask, 'Are we there yet?' on family road trips. They learned that asking doesn’t speed things up; if anything, it slows us down. Unfortunately, many project managers don’t understand that and it makes me sad. And there’s a lot of hate towards Rails—people ask why they should even bother using Rails. I get that, but DHH is a special kind of thought leader. Everybody seems to agree with everything he says. So my opinion about this starts with 'ball' and ends with [__]. It’s like introducing your kid to their first steaming dump—what has parenting become?
00:07:30.960
There are three hard problems in computer science: caching, validation, and naming things. DHH—yeah, he’s cool. If it weren't for him, none of us would be here. Changing requirements are part of software projects. Yes, requirements will change, and no project is special in that regard. Software changes, and if you can build a system that enables change instead of inhibiting it, you are on the road to success.
00:08:06.559
But my advice is simple: quit whining and appreciate how fortunate you are to be working in software, building amazing things, meeting awesome people, and, of course, watching me speak! It’s the best job ever! Even better than being a software developer back in 2014—enjoy it, and quit whining! You’ve done your rails new or you’re looking at a pre-existing project. You git clone it and think: 'I didn’t sign up for this [__].' Nope. You’re left thinking, 'I can’t deal with this!'
00:08:40.720
So what do you do? Do you get the [__] out, or do you care enough to try and fix things? Here’s my patented five-step plan, but honestly, it’s mostly a bunch of jokes interspersed with slides. I never promised I’d teach you anything. Step one is perception. It’s crucial in software projects. There are always people who maintain a relentlessly positive outlook on everything they do, even when shipping features they don’t believe in. Positivity is vital, especially in a leadership role.
00:09:27.599
Imagine you step in for a stand-up meeting full of enthusiasm, having just returned from a conference. You start sharing good news, but then someone named Bob chimes in with negative vibes, saying everything is terrible. Okay… thanks, Bob! Next time, can we skip over him? Positivity is paramount; it really influences the team dynamic! Another point is being opinionated. Working on a team with strong personalities can be great. If you express an opinion—let’s face it, we all express opinions about code constantly—do so through pull requests. That’s the best way to share your thoughts and reach consensus.
00:10:20.080
And then there’s the broken windows principle. This term originated from the mayor of New York. The idea is that if one broken window or piece of graffiti exists, it gives the impression that the area isn’t worth caring about, leading to more broken windows or graffiti. In code bases, it works similarly. If there’s a lack of clarity or intent in a piece of code you’re about to work on, tidy it up; your aim should be to leave the code cleaner than you found it.
00:10:33.440
Refactoring time is junk. You don't need permission to make improvements; that should be the norm in our industry. Of course, it’s better to seek forgiveness than to ask for permission! Step two involves capturing some form of metrics about the code you’re working on. Continuous integration (CI) is vital, serving as a nice environment for gathering metrics. You could use whatever you prefer, like Travis CI or CodeShip.
00:12:00.400
Another interesting aspect is code style. The code you write needs to be clear and carry its intent. There are two audiences for your code: the machine, which is incidental, and most importantly, another human being—so write your code for clarity. You can use a style guide to ensure consistency in your codebase. RuboCop is an excellent tool for this; it applies style guides to existing codebases.
00:12:49.120
With RuboCop, you can apply auto-corrections to your code. But before you start rolling out changes across your entire codebase, ensure you have solid test coverage. SimpleCov is a handy tool in this regard. Some might more loosely associate coverage with quality, but when combined with cyclomatic complexity, you gain valuable insights. Cyclomatic complexity measures the branching in your code—every if statement or control flow increment adds to the complexity score.
00:13:39.840
The more complex code often requires more substantial tests, so work towards maintaining well-structured unit tests. Another essential metric you may encounter is duplication. While certain tools like Flay help identify duplication, don’t treat all duplication as bad. Drying your code is a commonly misunderstood term; it means having a single authoritative representation in your code.
00:14:07.440
Churn is another useful metric for spotting issues in your codebase. If you see frequent churn spread across your project, it indicates that you might not be succeeding in packaging your software properly. Tools can help manage these metrics in your applications. Code Climate, for instance, is beneficial for understanding code quality at a glance. While it covers a lot, don’t overwhelm yourself by capturing unnecessary metrics. Make it known to stakeholders; when team members see coverage ticking up and complexity lowering, it can create a gamified aspect that motivates the team.
00:14:49.120
Moving on to step three: testing. When you explore specs directories and see they’ve written tests but find they are low-quality or non-existent, it can be disheartening. Tests can be transient; deleting poor tests is okay. It’s a common misconception that tests are sacred artifacts. Delete what you don’t need; it won’t result in chaos. Just because there’s zero coverage doesn’t mean you can’t introduce feature specs, whether they drive a browser or not. Sometimes, creating lower-level feature specs surrounding domain concepts is sufficient.
00:15:40.600
Speaking of tests, if you come across poor or slow unit tests, remember they were created during different phases of development. You can delete them! So to recap: tests are not sacred artifacts; they can be eliminated. Moving on to step four: improve your test coverage. Strategize changes you’ll be making, then it's time to seek and destroy! Go through your codebase and mercilessly reduce the surface area of your code. Be selective and identify low-hanging fruit that won’t require too much effort to address.
00:16:37.760
Sure, being just one undo away from passing tests is scary. The danger is that failure could lead to flipping tables out of frustration. Versioning Rails is also worth noting. A pattern I've observed with old, problematic projects is consistently neglecting to keep up with the latest versions. By integrating early and addressing version bumps, you set a solid foundation for the future.
00:18:19.520
To cap off my five-step plan, keep it unicorn at all times! If you feel comfortable with capturing metrics, don't hesitate to make the build fail on check-in when necessary. Continuous improvement is essential. As you progress, focus on perception, metrics, tests, reducing code complexity, and ensuring you maintain the unicorn ethos. We’re approaching the end of the talk and I hope you've enjoyed it so far!
00:19:27.679
Some of you might be familiar with Foursquare. Let me introduce an interesting idea: imagine Foursquare for sharks! It’s a real thing. You can get real-time information about shark sightings in your area. Maintaining light-hearted fun and creativity while working with technology is vital. Just this morning, I reached out to the people behind this and—believe it or not—five seconds before this talk started, they replied!
00:20:11.600
Their response was something like, 'Well, you’re going to regret that!' I replied back, but I haven’t checked for a response. Who knows? They probably just called the police and are arranging my deportation as we speak! It’s all in good fun. So, that’s me. Thank you all for listening; you’ve been a fantastic audience!
00:20:38.480
If anyone has questions, feel free to ask! And just so everyone knows, the queen is fine. We don’t hang out as much as we used to. She’s gone more into the single-page web apps route nowadays, which I don’t quite agree with, but she does her thing and I do mine.
