Author: Ryan Hayes

The Illusion of Code Quality

Code quality is something that I believe every developer strives for.  We want code to be the best it can be and there are tons of opinions on things developers can do to make quality high. Over the years as teams have moved to Agile from Waterfall, and as build and test automation has become better, a lot of the code quality metrics that experts have developed are becoming less helpful, or, dare I say, counter-productive. The larger a team gets, but more importantly, the higher turnover gets (developers leaving the team/company and new developers without context come on to the team/are hired), the harder it is for code to remain high quality over time. We’re all human, we can’t keep everything in our head, we can’t mind-read the original developer who left the company and wrote this code. The worst part is that we don’t know what we don’t know. We duplicate effort because we didn’t know there was a design document on Box, or we don’t go update it.  There’s also setup information on the Wiki that should be changed, but we’ve not asked anyone where it is yet, because we didn’t know to, so our sweeping changes to the project aren’t reflected there.  We’re also on a deadline, and there were already existing comments that StyleCop saw, and it can’t automatically tell me that something in my code is now out...

Read More

Personal Branding for Software Developers

I recently gave a talk on branding for software developers at TriJS.  While I didn’t get a chance to record it, I did upload the slides for your viewing please.  The slides are readable without listening to the talk and have a few protips and specific actionable things that you can do to boost your personal brand as a developer.  It’s one of those things where you don’t really need it until you want to change jobs or you need to promote something, then you wish you did.  If you don’t know how to get started, take a look at the slides and let me know some of the things that you’ve done to increase your visibility as a software...

Read More

TDD 0 to 60: How to Introduce TDD to Your Team With No Unit Testing Experience

Does your team use Test Driven Development or even unit test at all?  If you’re like a lot of teams I’ve come in contact with, that answer would be a resounding “no”.   I’m not sure what the biggest barrier is for most people, though I think it’s a combination of the following: “There’s barely enough time to write the application code, let alone test code!” “I’m not even sure what kind of test to write.” “We already have QA guys for that!” There are a lot of things that hold back many teams from it.  Where do you get started?  Let’s address these common questions and show how easy it is to get started with testing and TDD. No time? ROI increases with size and complexity. While it’s true that tests can take up valuable feature time at the very start, automated tests are an investment.  Unit tests take time to write, but the ROI dramatically increases the longer a project lives and the more developers are simultaneously working on the project.  With increased lifespan and size of a project, you run the risk of forgetting that changing a particular component interacts with and can break another component if it changes.  With no tests, it’s up to you or the QA team to catch this.  When you first write the feature, it’s easy to manually test, because you’re IN the...

Read More

Automating the Web with Selenium and WebDriver

I recently gave a talk on browser automation and using Selenium with WebDriver.  Not only that, I gave a demo of using Selenium, WebDriver, xUnit, and creating a fluent API to create a framework that makes tests easy to compose.  Check them out and let me know what you think!  Selenium is a fantastic way to get a ton of value from automated front-end...

Read More

Pin It on Pinterest