Managing Success: We made it, now we're screwed.

Testing

Mike Moore

#software-development

#testing

#startup-culture

Managing Success: We made it, now we're screwed.

by Mike Moore

In the video titled "Managing Success: We made it, now we're screwed," Mike Moore discusses the challenges faced by developers in the Ruby community as they navigate the complexities of successful applications. Drawing from his experiences, he highlights a variety of issues including code quality, team dynamics, and the significance of testing. The main theme revolves around how success often leads to problematic code due to pressure, lack of structure, and poor communication within teams.

Key points discussed include:

- Success vs. Quality: Many developers find themselves working on applications that degrade in quality despite their success. Factors such as poor initial design, lack of experience, and high turnover impact the longevity and maintainability of these applications.

- Monolithic Architecture Issues: Moore emphasizes that a common problem in Rails applications is the single monolithic architecture, which complicates maintenance and understanding. He points out that many applications do not have a clear separation of responsibilities, leading to convoluted code.

- Testing as a Core Practice: He stresses the importance of testing, distinguishing it from quality assurance. Good testing practices can alleviate the pain of maintaining monolithic applications. Moreover, he asserts that tests should serve to clarify the application's intent and support developers during refactoring.

- Maintaining Abstraction Levels: Moore advises maintaining consistent levels of abstraction in code, recommending the use of helper methods and presenters to separate concerns and improve code clarity and testability.

- Human Element in Development: The speaker underscores the need for strong team dynamics and collaboration beyond technical skills. He argues that nurturing existing talent and fostering good communication are keys to overcoming the challenges of software development.

- Final Takeaway: The journey of software development is intertwined with building relationships and a supportive team culture. Collaboration and appreciation of each other's skills are essential for creating scalable applications that truly meet business needs.

00:00:24.800 The thoughts I had my first semester's proposal and where I ended up now is a little bit different. I'm not going to be quite as technical, but I will do my best to see.

00:00:39.440 Before I start, let's see a show of hands. Who here is working on Ruby? How many of you have ever joined a team with an existing app because it was growing and successful? All right, that's the majority. How many people here have ever hired someone to join their team because the app you were working on was successful? Okay, so one thing I want to talk about is how we move forward with success.

00:01:14.960 The first thing I want to get out here is that you might be a pain to your business. They do not like you; they don't care about your app, and they don't care about your code quality. They only deal with you because it is financially worth it for them. The amount of pain they deal with varies by company. Some places will put up with dress codes, while others will allow remote work. But at the end of the day, every company has a different pain tolerance when dealing with you, and their pain is not your pain.

00:02:01.759 Who here has worked on an app that's a piece of junk? Raise your hands. How many people have worked on a Rails app that's a piece of junk? Okay. I'm really curious as to why the apps we work on often turn out poorly. We're all self-selecting developers; we're here because we want to improve. Yet we often find ourselves working on assets that are of low quality. Why is that? One reason is that some apps were designed as demos but were then shipped straight away, which is a bad practice.

00:02:34.400 Another reason is the lack of experience of the original team. High turnover and inconsistent code quality contribute as well. If you ever find yourself needing to understand the anthropological history of your app to grasp why certain decisions were made, that is a clear sign of a bad app.

00:03:11.800 Is anyone here familiar with Conway's Law? It states that organizations which design systems are constrained to produce designs that mirror the communication structures within those organizations. This relates back to the point where you are a pain to the business. Sometimes, business people don’t want to communicate with you because they don't have a vested interest in it. This lack of communication structure will manifest in your app.

00:03:43.760 Now, I find it frustrating that we can work with Ruby but face pain in our apps due to influences outside our group. Early on in the Ruby community, I learned that Ruby is designed to make programmers happy. It pains me when I'm not happy while working within this environment.

00:04:14.879 I’ve worked on multiple applications over time and faced similar issues repeatedly. What's the number one problem we encounter? If you could summarize the issue with Rails apps that makes them difficult to maintain in one word, what would it be? The answer? The single monolithic architecture throughout the entire application. This is the biggest issue.

00:04:43.760 I've transitioned between companies and organizations, and the most significant problem I see is apps that are just a monolithic ball of mud. They do way too much, and that distresses me. Typically, this indicates there's no clean separation of responsibility within the model.

00:05:01.680 Have you ever opened up a Rails app, and it has like 25 controllers and 23 models? Everyone here has worked on apps like that, right? That’s terrible. On the flip side, you may have a situation where your models are overly complicated, as they just took a 2000 line post model and split it into different files. This isn't a sign of good structure; it's a sign of a very fat model.

00:05:51.680 Unfortunately, Rails makes it easy for developers to shoot themselves in the foot. While Rails provides good conventions for MVC and tells you where your code should go, it offers very little guidance on structuring it properly.

00:06:43.920 So, I want to first discuss the models. Your models typically end up getting the majority of attention in our apps. But before that, I want to take a slight detour and discuss testing because it's another major issue.

00:08:03.760 Who here has ever been paid to work on an app that has very little testing? Let’s be honest; that’s pretty much everybody, right? This is an ongoing issue. And who is currently working on a project that has subpar testing? Again, that seems to be the majority.

00:08:53.600 We're not all going to become masters at testing overnight. However, I want to touch on a couple of key points about it. The first is, testing is part of development, and it's not quality assurance (QA). Tests should ease pain, similar to how businesses endure pain to gain value from us and the applications we build.

00:09:50.560 We have pain in many areas that testing can help address. The first pain is determining what the app is supposed to do. Test-driven development provides guidance, laying the groundwork for what the application is meant to accomplish. Additionally, tests aid in easing the pain as we refactor our application. However, we shouldn’t confuse testing with QA.

00:10:24.799 When dealing with monolithic apps, pain is inevitable, and testing can alleviate that. The issue with many apps lacking good test coverage stems from the distinction between non-test driven lines and those that are test-driven.

00:11:11.760 The curve for those without tests climbs steeper over time, as fixing bugs or adding new features results in higher costs. Developers sometimes choose not to include tests as they believe it will prolong the development process. What results is a perception that testing equals pain, which needs to change.

00:11:46.240 We often confuse testing with development time. In reality, model tests are cheaper and yield better returns than comprehensive browser-based tests. Integration tests can provide a false sense of security, while model tests offer deeper insight into our applications.

00:12:04.560 When approaching Rails apps, I have two rules: I want declarative code, meaning I prefer code that states what it does instead of how, and I believe in maintaining consistent levels of abstraction. For instance, if you're breaking down processes, ensure it’s done within different methods to avoid convoluted logic.

00:13:43.760 Here's an example—using a helper method that declares actions like joining or dropping a course, rather than embedding complex checks within your views. This approach consolidates logic and clarifies intent, making it much easier to maintain and test.

00:15:17.680 To emphasize the significance of level of abstraction, when faced with complex if statements and conditionals, it's better to delegate functionality to helpers rather than cluttering views. This practice leads to more maintainable code, improving testing and overall quality.

00:16:04.799 Additionally, making use of presenters to encapsulate view logic is invaluable. Presenters can serve as view models, helping separate concerns, which allows for easier testing of logic that would otherwise be buried within views.

00:16:55.360 Throughout different levels of our stack—models, views, services—we need to ensure we focus on splitting our applications correctly. There’s a wonderful book called Real-World Software Development Patterns that I recommend.

00:18:18.880 As we explore success, how do we build a team around it? What does it mean to code effectively? Code represents someone else's problem. It's how we transform abstract ideas into concrete forms. The legendary book, The Structure and Interpretation of Computer Programs, emphasizes that computer science is about controlling intellectual complexity, and programming is inherently a human activity.

00:19:26.880 The reason we struggle with software is often due to our culture's tendency to minimize the human aspect of our work. Focusing solely on machine efficiency can lead us astray; hence, we must prioritize human interaction and communication in programming.

00:20:44.720 I genuinely enjoy being here at conferences because the audience here is self-selected; you are passionate about improving your craft. However, I do wonder about the 80% of developers who aren’t here. We can spend time establishing coding standards, but our work is intertwined with ideas, and we must not underestimate the importance of collaboration.

00:21:34.720 The human element is essential in achieving scalable applications that meet business needs. While it may seem tempting to focus only on attracting top talent, the true solution lies in nurturing and enhancing the skills of the developers we already have. Everyone has potential, and we can foster growth.

00:22:12.960 The dynamics of the team are crucial. It's not enough just to assemble a group of talented individuals. Without fostering good team dynamics, even the most talented teams can become dysfunctional and fail to deliver.

00:23:05.440 So remember to prioritize collaboration and support among team members. You all are amazing, and the message I'd like to leave you with is to embrace and appreciate the journey of working together, because ultimately, friendship is magic.

LA RubyConf 2012