00:00:09.400
All right, good morning! My name is Jeff Casimir. I started a company called Jumpstart Lab, and this is a talk called 'There Are No Tests.' It's about testing and rescue projects.
00:00:15.240
Yesterday, I had to buy some of your favor with cupcakes. I hope it worked. I wanted to inject a little happiness into the room because this talk is a bit of a downer. Consider it my happiness offset; we were happy, and now we can bring you back to normal.
00:00:26.720
It's going to be a little serious here. If you write software, you have probably written crappy software. Ryan, when was the last time you wrote crappy software?
00:00:37.840
Thank you! If you don't write crappy software or you don't think you write software that is crap, the bad news is you will. You must be writing it today.
00:00:45.640
Your bad software becomes someone else's problem. Maybe that’s after you get fired and someone else comes in to take your place, or maybe it’s future you six months from now, looking back and asking, 'What was I thinking? Why did I do it that way?'
00:00:51.640
And if you haven't done this yet, you will. I do it frequently. I look at things I've used to teach people and things that I've written, and it's just like, 'Oh God, no.' Projects go wrong, but that doesn’t mean they can’t be turned around.
00:01:05.960
In writing software, we have a unique privilege that most professions would love to have. If you were a doctor, imagine what it would be like to ensure that your cure would fix your patient. Medicine is mostly about trial and error.
00:01:13.759
They have these ideas, things that have worked six out of ten times. They try it and hope it fixes you, but there's a decent chance it won’t work.
00:01:21.560
In software, you have the privilege of ensuring your work succeeds. Yet, many of us throw that privilege away.
00:01:27.680
This is a quote from my friend Joe Br who I heard planted his sister here somewhere as a spy. I think it links back to what Michael mentioned yesterday about software architecture reflecting the people behind it.
00:01:34.560
Projects that go wrong are rarely due to technical reasons; it's usually people reasons. The technical problems become a symptom of deeper issues.
00:01:45.319
So, tech solutions alone can’t fix these problems. We can’t fix people by writing tests or by migrating them to the latest version of Rails, even though that may seem like it could work.
00:01:52.520
However, having a structured approach can guide us in a positive direction and help set us along the right processes.
00:02:01.399
Let’s talk about these rescue projects. There is a perception that rescue projects are for those who couldn't get better projects.
00:02:08.280
It's as if people think, 'Oh, no funded startup wants to hire you to build their app. Here, take this previously funded startup and try to make it stop crashing.'
00:02:15.680
The truth is rescue projects are some of the most noble projects. I believe they are the hardest.
00:02:27.680
When you go into a fresh application, you have the chance of being successful from day one. When you enter a rescue project, day one is going to be ugly.
00:02:33.720
No one brings you in because everything is cool; they want to call it a rescue because everything is not cool. Day one is going to be ugly, and so will day ten.
00:02:41.120
Hopefully, month ten will get better, but you go in knowing it sucks, and that’s okay. Life is not about doing easy work.
00:02:48.479
Rarely will you look back and say, 'Man, that job I did was easy, and that was the best work of my life.' Instead, we'll look at the challenging work that made us question what we do and how we do it.
00:02:56.480
Those are the projects we’ll be proud of.
00:03:01.879
When I started my professional career, I began with Teach for America. I wanted to get into teaching and decided that I could teach at the private high school I attended.
00:03:10.680
They would have taken me, but I chose to go to a place where others were unwilling to go—trying to tackle the problems, challenges, and failures.
00:03:17.240
With rescue projects, you are making the same choice: to go into the fire, push back, and be stronger than those who came before you.
00:03:25.440
So, seek challenges because life is not a Greenfield; you can’t just burn it down; you rescue.
00:03:30.280
Step one of a rescue project is not to rm -rf star. You have to get in there and understand why it went wrong.
00:03:37.160
Fixing complex systems is much harder than starting new ones. If you want to be a programming hero, you must tackle rescues.
00:03:43.440
The first thing you need is expertise. A novice cannot fix a project that is on the wrong path.
00:03:48.960
You need the ability to break down complexity, fix architecture, and understand how code and business interact.
00:03:55.600
If you’ve been programming for six months, you can’t do those things. After three years or five years, you might start to develop that ability.
00:04:02.199
You also need passion; you have to love what you do. But more than that, you have to love people.
00:04:10.559
That is not something we necessarily excel at in software development. You've got to understand you're dealing with a people problem.
00:04:19.640
The software is a symptom of a people problem, and you have to enter the project caring about the people involved.
00:04:25.360
I care about your business, and I will help you succeed.
00:04:34.360
It's like believing in the change you can make in the world.
00:04:41.120
Lastly, you need determination. In Teach for America, we talked about the relentless pursuit.
00:04:47.560
That was always the quote: relentless pursuit.
00:04:53.440
I remember my second day teaching third grade, sitting in the classroom and crying at 22 years old, wondering, 'What have I done with my life?'
00:05:01.920
But I came back to that principle of relentless pursuit and told myself, 'Nothing can break me.'
00:05:09.600
In a rescue project, you will deal with frustration. Frustration from the code you wrote, the code someone else wrote, or the people who have been scarred by past developers.
00:05:17.120
If you don't have that relentless pursuit ethos, you'll give up.
00:05:23.680
Now, let's discuss goals. Once you decide you're going to tackle a rescue project, you need to set goals.
00:05:30.280
An expert without goals, without a plan, is like debt. Without measurable goals, success by definition is impossible.
00:05:36.480
You would never know when you've achieved success; you'd just stop at some point and think, 'Oh yeah, this seems good.'
00:05:43.760
So, the only way to succeed is to set measurable goals and then measure them.
00:05:50.400
You're entering a jungle when you walk into a project that you know is a mess. Without direction—the guiding light of measurable goals—you will walk or code in circles.
00:05:57.680
In the big picture, there are three possible outcomes.
00:06:05.160
First is failure. If a rescue project fails, there's a temptation to say, 'It sucked before I got here; it didn’t work out. It probably wasn’t my fault.'
00:06:12.880
But there’s more to it. Many of these projects involve massive companies with billions of dollars, and it doesn’t matter.
00:06:19.040
But a lot of projects get into rescue status because they scraped together every dollar they had to invest in that project.
00:06:25.120
They couldn’t afford to hire experts, so they went with someone in their basement, pleading, 'Please, this is my dream, but it’s now going down the drain.'
00:06:31.640
When a project fails, it’s not just about software getting tossed aside; it’s about lives, confidence, jobs, and families that are impacted.
00:06:39.760
The second outcome, and perhaps the most common, is survival. This state is stressful; it’s full of uncertainty and mistrust.
00:06:46.240
It's like saying, 'Oh yeah, it kind of works. It’s staying up. Okay, but it's no way to live.'
00:06:53.280
A survival project is where you get text messages late at night saying, 'Oh my God, everything is down.'
00:06:59.440
You can keep it going; keep putting foil on the ball, but you're not making real progress.
00:07:07.200
The third possibility is thriving: success, profit, happiness, and trust.
00:07:14.560
Imagine the new things that can come from a truly thriving project: making money, happiness, and harmony.
00:07:20.960
Everyone says, 'Can we hire you to do more things?' What do you want to build? Can you imagine that?
00:07:29.120
There was a sad quote I came across a year ago at a business conference about customer feedback. It said, 'Get quotes from your customers early in the project; that's when they're happiest.'
00:07:39.680
Damn! Is that really the standard we are setting for ourselves?
00:07:46.480
Can we look back at our projects and think about how at the beginning everyone was excited? But by the end, it felt like a nightmare.
00:07:54.640
Progress is about goals, but goals mean nothing without assessment. Being agile doesn’t mean having no plan.
00:08:01.600
Instead, it means constantly correcting course, heading toward the guiding light of your goals.
00:08:08.880
You can’t change course without new information. If I'm trying to get somewhere, I check my map and then walk, but there's a risk I might get lost.
00:08:16.440
It’s much more likely to succeed when I'm following my phone's GPS, gathering constant information to change direction.
00:08:24.640
So how do you measure progress? The first benchmark is code coverage.
00:08:30.240
Coverage is definitely a flawed benchmark; it’s somewhat artificial. You can pump up code coverage, but it's rare that a project has good coverage and bad tests.
00:08:40.560
However, I never say, 'Oh, this code is too covered.'
00:08:47.560
Where it gets interesting, and I don’t think many people focus on this, is the metrics of velocity—both of new features and fixes.
00:08:54.720
How long does it take for a new feature to be added? When we do estimates and say a feature is worth three points, how often is that estimate accurate?
00:09:01.960
If everything we're estimating at three points takes five points of time, our progress isn't indicative.
00:09:08.840
As the software project deteriorates, velocity slows down. That is a rare occurrence; however, in a rescue project, you have the chance to speed it up.
00:09:17.120
You can do this because complexity is likely already quite low.
00:09:24.520
We're fortunate to have amazing tools. I credit Seattle RB for their work in this area.
00:09:32.679
They have built terrific tools with Metric Fu, Flog, and others that provide these valuable insights.
00:09:40.399
But if you have a method that is scoring very high complexity, you need to dig into why that is happening.
00:09:49.120
Faults: what percentage of your users encounter a fault? How about the percentage of transactions that meet that criteria?
00:09:56.280
That is often overlooked. Your response time is measurable, but response quality is tougher.
00:10:03.560
If you are Google, response quality might mean that when someone searches, how frequently do they search again?
00:10:11.160
When someone uses our feature, do they get what they expected? That's something to explore.
00:10:18.080
Finally, the most significant metric is value—whatever your business domain is, including signups, sales, and more.
00:10:27.360
If you measure all those aspects, you can see progress over time.
00:10:35.680
But none of this is possible without breaking the cycle. Projects don’t move towards order; they tend towards chaos.
00:10:45.680
They tend towards complexity, like the graph Michael showed, with 80 billion metric nodes interconnected.
00:10:53.840
Just changing the developer isn’t sufficient to guarantee success.
00:11:01.920
The client needs to be committed to making changes too.
00:11:09.760
There's an interesting book called 'The Clean Coder,' written by Bob Martin, which explores professionalism.
00:11:17.520
It analyzes language use, particularly the word 'try.' This word signifies a lack of commitment.
00:11:25.440
When dealing with a rescue project, you are approaching damaged people.
00:11:32.080
Clients may want to waste your time because they don’t know how to write effective bug reports.
00:11:39.039
If you normally contact clients once a week, consider doing it once a day with rescue clients.
00:11:45.200
For example, every week, developers at Envy Labs, down in Florida, send screencasts of features they've built.
00:11:52.960
Such communication can be reassuring for clients—allowing them to see continual progress.
00:12:00.160
All that matters is building trust with clients and proving that their success is your goal.
00:12:08.320
Discipline and trust: trust comes from expertise and consistent application.
00:12:16.160
Clients need to see you actively working, which breeds confidence.
00:12:23.160
They believe you when you say changes need to occur, such as switching cloud providers for more efficient I/O.
00:12:31.160
When you earn their trust, clients often turn into advocates, which is beneficial for any business.
00:12:38.960
If I am comfortable in a project, I need to know those key principles.
00:12:47.520
There are many aspects of the project where I can be flexible, but I must insist on measurable gains.
00:12:55.800
I see a commonality in struggling projects is deployment. If a project can’t be deployed with one command, that should be a priority.
00:13:03.360
Deployment isn’t just about getting features out; it represents communication with clients and stakeholders.
00:13:12.160
The more you deploy, the quicker the feedback loop, and the quicker you can adjust and succeed.
00:13:21.519
As my friend Brian says, I’d suggest deploying often—it shows clients that progress is being made.
00:13:30.000
If you say you’ll deploy in three months, it’s unlikely to work. Monitoring becomes crucial.
00:13:37.680
Monitor runtime, value, coverage, and complexity. Monitoring becomes routine, like part of your deployment process.
00:13:46.640
If you can't consistently generate data about your project, you are not collecting crucial metrics.
00:13:54.000
Now, let’s talk about tools, strategy, and clients.
00:14:02.560
Without tests, long-term success is improbable. I won’t say it’s impossible, but it is highly unlikely.
00:14:10.640
Professionals need to do professional work. Tests are not just about validation.
00:14:19.520
If a person asks, 'Why should I write a test?' because they can manually click through and see it work, that’s misguided.
00:14:28.640
Yes, it worked at some point, but that does not mean it’s reliable.
00:14:37.840
You must consider whether adding a new feature will disrupt existing features.
00:14:45.040
This common sense does not imply that everything will continue functioning without problems.
00:14:53.360
There’s a rule of thumb: projects spend about 30% of their time constructing and 70% on maintenance.
00:15:02.240
Testing does impede construction. Unless you are highly proficient, you probably produce software slower than someone who doesn’t test.
00:15:10.640
However, the long-term maintenance will be exponentially more manageable.
00:15:18.240
The most deficient code we write is often intentional neglect.
00:15:26.480
Our worst programs become neglected because they were never meant to be used past today.
00:15:34.800
When you look back, you’ll wonder, 'Why did I write such carelessly?'
00:15:41.960
There are no miracles when it comes to writing automated tests.
00:15:50.160
Clients will most likely not suggest dedicating a month just to write tests.
00:15:57.840
Progress comes gradually through small steps. Projects are built or destroyed, one commit at a time.
00:16:05.560
If your project lacks tests, consider that every test you write increases the amount of tested code.
00:16:13.200
So, you should focus on being a developer you’d want to work with.
00:16:21.039
Fixing one tiny issue and writing a test for it can lead to progress for tomorrow.
00:16:29.280
To ground this in reality, let’s talk about practical steps in the context of Rails apps.
00:16:37.760
If you’re working on a rescue project, some easy first steps involve testing relationships.
00:16:44.080
Many people avoid testing relationships because they think testing Active Record basics.
00:16:52.160
In reality, you need to confirm that one Active Record object relates to another, which differs from testing the core of Active Record.
00:17:00.440
Testing validations can also be pivotal. Many bugs arise early in the data lifecycle.
00:17:08.240
Testing calculations, particularly in models, can quickly clear up what’s happening.
00:17:16.320
There’s also a mixed love-hate relationship when it comes to testing helpers.
00:17:23.120
These are also quite easy to test!
00:17:29.360
The concept of refactoring for understanding means looking at code not just for quality, but rather to see how different parts are affected by change.
00:17:36.200
You can pair manual testing with code extraction.
00:17:43.680
You find complexity, test it manually, and extract components so that you can validate what remains.
00:17:51.360
Comment-driven development means commenting out code to ensure that when you break it, you can test the breakage.
00:18:00.080
Once you determine what breaks, do not uncomment the code; continue to utilize TDD principles while building.
00:18:09.280
This will allow you to examine concerns that may not have appeared before until you start building.
00:18:18.080
Rescue projects often involve firefighting. They don’t find you when things are going well; they come to you when everything is crashing.
00:18:26.080
So, your process must balance firefighting with long-term investments.
00:18:34.320
If you're constantly fighting fires without investing in the system, you’ll be stuck in that cycle forever.
00:18:42.720
Problems stem from misunderstandings. No one sets out to create complex code.
00:18:50.680
Complexity arises as you pile on guards, if-conditions, and more.
00:18:58.360
If you're feeling overwhelmed, write tests for the most critical functionality and pending tests to denote future work.
00:19:05.680
Pending tests act as documentation and provide context for future adjustments.
00:19:12.560
Now, let me ask you a question: when a stakeholder reports a bug, how many emails does it typically take to fix it?
00:19:20.240
Usually, you get the email saying, 'It’s broken.' And when you ask for details, it’s like pulling teeth.
00:19:26.600
There’s a clear communication problem here. What if we standardized bug reports so that they were more efficient?
00:19:35.680
By teaching clients to articulate their issues in a structured format, they might provide information that’s easier to use.
00:19:43.520
If you had a template for bug reporting, how much smoother would problem resolution be?
00:19:50.240
Treat bug reports as integration tests; they should provide valuable insights.
00:19:58.760
In conclusion, rescue projects require courage to solve tough problems.
00:20:05.840
Set measurable goals, as that’s essential for success.
00:20:12.800
Avoid repeating the mistakes of those before you.
00:20:19.680
Work incrementally, concentrating on small, manageable steps.
00:20:26.339
Remember that fires represent weaknesses, and resolving them makes your project stronger.
00:20:39.120
By saving a project, you’re not just saving a product; you’re saving jobs, money, and potentially, the world.
00:20:47.280
My name is Jeff Casimir, and at my company, Jumpstart Lab, we teach the best Ruby on Rails training courses on Earth.
00:20:55.040
And as for my Twitter handle, you can't have it; it’s only two letters!
00:21:05.640
Do I have any time left? No? I’m already over. Who needs a break?
00:21:12.880
Got to stretch a bit. Any questions, objections, or thoughts?
00:21:21.920
I know you probably put the hate on Twitter, so feel free to share there.
00:21:30.560
I wish I could say it was that simple, but often, clients send lengthy email chains regarding bugs.
00:21:41.760
It’s a complex issue, but I'm glad we’re engaging in this conversation.