"What were they thinking?"

Talks

Keith Pitty

2 talks

#software-maintenance

#test-driven-development

#developer-experience

"What were they thinking?"

by Keith Pitty

In his talk titled "What were they thinking?" at RubyConf AU 2019, Keith Pitty delves into the common challenge faced by developers when grappling with legacy codebases. He poses the critical question of how one can avoid creating a state of code that leads others to wonder about past decisions. Drawing from his extensive experience in software development and his involvement in the Australian Ruby community, Pitty outlines several key strategies to ensure codebases remain maintainable and understand the human factors involved in software creation.

Key points covered in Pitty's talk include:

- Understanding Design Quality: Emphasizes the significance of internal software design and how adherence to design principles, like those of simple design proposed by Cory Haines, can prevent issues.

- Refactoring as a Practice: Defines refactoring and its role in improving code structure, highlighting the necessity of automated testing to maintain code integrity during refactorings.

- Importance of Upfront Planning: Advocates for thoughtful design before coding, citing Simon Brown's C4 model that encourages considering context and architecture to avoid future complications.

- Peer Review Culture: Discusses various forms of code review, including pair programming and pull requests, and highlights the need for consistent code evaluations to enhance design and detect mistakes early.

- Maintenance and Technical Debt: Stresses the need for a culture of regular maintenance akin to car servicing, including load testing, security updates, and keeping software current.

- Influencing Stakeholders: Talks about the importance of communication with business stakeholders, underscoring the need for software developers to effectively advocate for practices that lead to high-quality, maintainable code.

- Continuous Flow Philosophy: Introduces a philosophy that moves away from traditional project-based work towards a mindset of continuous delivery and value generation.

- Agile Principles Reevaluation: Reflects on how Agile methodologies should simplify collaboration and delivery instead of adding complexity to development processes.

In conclusion, Pitty suggests that developers can prevent the legacy code dilemma by practicing discipline in their coding habits and honing their persuasive skills to communicate the value of robust development practices to stakeholders. His experience serves to encourage a communal responsibility towards software maintainability for future generations of developers.

00:00:00.030 Next, we have Keith Pitty. Keith is a seasoned software developer who has been writing Ruby since 2006. He has been an active member of the Australian Ruby community since the first Rails came in the winter of 2007 and was the president of the inaugural Ruby Australia committee. If Keith is passionate about cricket, and you happen to engage him in conversation about it, you can ask him to explain what a silly leg or a cow corner is, or what a deep backward point means. There's so much strange, yet perfectly good, terminology in the sport.

00:00:21.449 Today, Keith's talk addresses the feeling many developers experience when working with a legacy codebase, thinking, 'What were the previous developers even thinking?'' Please welcome Keith.

00:01:21.290 Do you acquiesce and take shortcuts to meet expectations? Or do you strive for quality? Time passes, and you eventually move on to work for other organizations. More time passes, and one day, years in the future, you find yourself at a Ruby conference. By chance, you meet several developers who are now working for your old shop, and you cringe with guilt in your stomach.

00:01:36.800 How can you avoid being that developer who feels compelled to apologize profusely for past mistakes? As we reflect on the scenario that introduces this talk, we should ask: how did the code possibly get into such a sad state? There must have been several shortcomings that led to the feeling of allowing peers the unendurable challenge of dealing with the debt-laden codebase you left behind.

00:02:06.799 Let's start by considering the design of that code. Note that I'm not referring to the design of web interfaces but rather the internal design of software. Was sufficient attention paid to this? How well did the development of your codebase stack up against what Cory Haines refers to as the four rules of simple design? These rules are indeed fine; they originated from Kent Beck, so they must be solid.

00:02:59.360 However, some of these rules prompt further questions. For instance, did sufficient refactoring take place? First, what exactly is refactoring? According to Martin Fowler, who introduced this practice over two decades ago, it's the process of improving the design of existing code. Those of us who have learned this practice know that it goes hand in hand with automated tests.

00:03:46.800 As we develop and want to pass tests, we have the opportunity to enhance the internal design, possibly with some collaborative thinking, so that those who come after us will be grateful. So, why are automated tests crucial? We can't improve the design of existing code with confidence if we don't have automated tests to ensure that the behavior remains unaltered as we attempt to enhance the design.

00:04:12.390 The imperative to strive for test-driven development and continuous integration is vital. In my view, automated tests that are not run in the CI server don’t count. If we have attended to the importance of design, refactoring, and automated tests, is that sufficient? I don't think so. Other factors might have led to technical debt.

00:04:38.680 Let's continue our reflection. As Dave Thomas, who hails from Canada and founded the Agile conferences, once said, 'Big Design Up Front is dumb; doing no design up front is even dumber.' In other words, it pays to think about design before we start coding. This gives us a better chance of success. I think Simon Brown's C4 model for software architecture is worth exploring here. C4 stands for Context, Containers, Components, and Code.

00:05:51.460 Simon presented this model in late 2017 and has provided excellent resources online. I encourage you all to delve into this further. Essentially, failing to do any upfront design could lead to a slippery slope. Not giving yourself a chance to establish a well-architected system may come back to haunt you later.

00:06:16.790 I wonder if our hypothetically embarrassed developer heeded today's advice. Another crucial aspect of healthy software development is peer review. This has long been recognized and has taken various forms over the years. Back in the 1980s, reviews occurred through structured walkthroughs, and now pair programming and pull requests on GitHub allow for immediate and asynchronous code review.

00:06:51.500 Reviewing code provides an early opportunity to catch bugs and improve internal design. As software developers, we understand this, but does it always happen? Do we sometimes succumb to the temptation of shortcuts? Is there pressure to speed up the process by skipping code review? All too often, this creates a tension between getting things done quickly and getting them done well.

00:07:40.000 Has the right balance been struck? While the goal of self-documenting code is laudable, is that enough? Has a helpful README document been created or curated for each code repository? Has a culture of providing useful guides been fostered within the repository? Ideally, there should also be a clear history of the reasons for decisions captured in version control.

00:08:15.830 What importance do we give to load testing before code changes are approved? How often is appropriate load testing performed, or is it often neglected? Is it more common to apply changes that degrade performance, resulting in worsening response times?

00:08:34.780 Let’s have a show of hands: how many car owners are in the audience? Keep your hand up if you ensure your car is serviced according to the recommended schedule. I’m glad to see that some of you do. But what about planned maintenance for software? Is that something we budget for? Do we perform the equivalent of changing spark plugs for our code?

00:09:05.800 Do we plan to keep our production systems updated with security patches? What about budgeting for keeping our Rails applications current with the latest releases? How many people here have supported a Rails application in production for at least three years?

00:09:30.950 Keep your hands up if it's running on Rails 5.2.2 and Ruby 2.6.1. Maybe that's a bit unfair, but you see where I'm going. On reflection, is it more likely that software maintenance is reactive? Do we wait until problems surface in production?

00:10:10.000 Now, let's consider technical leadership. Has there been sufficient scrutiny from a technical perspective? Have the voices within the technical realm been heard regarding the points covered today?

00:10:13.800 There is often a tension between technical perspectives and business imperatives. We want to ensure that the application can be maintained to support evolving business needs. Has there been enough negotiation to ensure that the necessary steps will be taken?

00:10:44.290 So far, we have reflected on the potential causes of a codebase falling into a sad state. What we need to do instead is set ourselves on a better path logically in order to ensure that an application is easy to maintain.

00:11:00.000 What we need to do is practice those points we've previously mentioned. Okay, job done? I guess that’s the end of the talk. Well, maybe it's not quite that simple. Perhaps there are other considerations.

00:11:30.100 Perhaps we will have a better outcome if we exercise more discipline, both individually and as a team. Crucially, we need to be prepared to patiently and clearly explain the importance of solid software development practices to business stakeholders. We will return to this theme later.

00:12:04.110 Now, at this point, I must clarify that I do not claim to have all the answers about how to negotiate better outcomes. However, I would like to share some suggestions based on my experience. Let's be realistic; the lives of software developers rarely proceed smoothly.

00:12:38.440 If we’re to be successful in the long term, we must remain vigilant and be aware of potential pitfalls. While we consider the pitfalls previously mentioned, there are other approaches we can take that might be helpful.

00:12:56.040 It may seem negative, particularly when we see shortcomings in the life of a codebase. I know I've certainly fallen into that trap before. However, wherever possible, I believe it pays to address challenges with a positive mindset.

00:13:35.850 With positive thoughts in mind, we can consider what could be a constructive overarching software philosophy. What does it mean to 'be at peace with evil'? I find it interesting that there has been a growing movement towards continuous flow as a philosophy for our industry.

00:14:07.790 One recent book by Evan Leybourn and Shane Hasty centers around this theme using the tagline 'No Projects' as a title. To me, Evan and Shane provide compelling reasons for resisting the impulse to form projects and instead focusing on generating a culture of continuous value.

00:14:52.230 Allen Kelly is another writer exploring this theme. I believe his book 'Continuous Vigil' is an important and well-reasoned contribution to this discourse. When considering this perspective, it extends the idea of continuous delivery, which emerged from continuous integration.

00:15:28.820 As Evan, Shane, and Alan suggest, there is often no need for projects or sprints. Instead, we should aim for continuous feedback. I encourage you to delve deeper into the concept of continuous flow and think about how it might benefit your organization.

00:16:11.910 Staying on the agile theme, it’s interesting to note that it has now been 18 years since the agile manifesto was established. Some approaches, like Scrum, exist even longer. We should ask ourselves how well the agile movement serves us.

00:16:53.080 Indeed, in 2016, one of the original organizers of the retreat that led to the agile manifesto, Alistair Cockburn, published a paper arguing that 'agile has become overly complicated.' The solution is straightforward: collaborate, deliver, reflect, and improve. These four tasks are already sufficient to cover the complexities of modern development.

00:17:32.320 Holger has advocated for stripping agile down to its core under the banner 'The Heart of Agile.' I encourage you to explore these principles and focus on their essence rather than getting mired in the various recipes for agile.

00:18:04.760 For example, we might reflect on how we can enhance collaboration and delivery by combining those imperatives. Collaboration also involves trust, for instance. Now, let’s examine the significance of careful explanation.

00:18:50.020 How can we best influence decision-makers to adopt practices that lead to long-lasting, well-maintained codebases? I have learned that mounting a forceful argument does not always yield positive results. Now's an appropriate time to recall the first slide of Sandi Mac's talk, which opened last year's conference.

00:19:45.160 Sandi left the audience with a thought-provoking statement while we waited for her introduction. She immediately captured my attention. She referenced several books to coax her audience into learning more about becoming influential. I highly recommend watching the video of Sandi's talk and reflecting on how you can apply some of these ideas in your attempt to persuade.

00:20:14.430 In essence, if like me, you often set out to win arguments, it’s better to be more prepared to patiently explain your viewpoint and add to a shared understanding. I emphasize adding to a shared understanding because this term is highlighted in the book 'Crucial Conversations,' which I strongly endorse.

00:20:59.450 As the authors emphasize, it is more valuable to contribute to shared knowledge than to attempt to convince everyone of your perspective. You may increasingly see that I am stressing the importance of people skills, as they play a pivotal role in ensuring a codebase remains in a good state.

00:21:26.990 What’s critical, in my view, is your ability to persuade others genuinely and patiently. This is a skill that requires practice. It’s relatively easy to improve technical abilities, whether conducting thorough code reviews on GitHub or implementing Continuous Deployment using tools like Docker.

00:22:03.480 The greater challenge lies in persuading stakeholders that these activities merit developer time. Building persuasive skills takes time. In some contexts, it will be more challenging than in others. Some stakeholders may be less open to listening.

00:22:46.370 In some situations, more creativity and patience will be required. Hopefully, your motivation will drive you to ensure your team's codebase has a fair chance at a long, fulfilling life. This goal should lead you to practice becoming more persuasive.

00:23:23.300 You will need to persist. If a particular approach to persuasion fails, pick yourself up and prepare to try a different method. If you find it challenging, consult others when necessary. Seek guidance and inspiration beyond your team.

00:23:49.770 As software developers, we continuously encounter new technologies to learn—be it Elixir, React, or the latest releases from AWS. That's good, but alongside mastering these tools, keep an open mind towards learning new methods that enhance your effectiveness in communicating. That is, communicating with individuals who may not comprehend the intricacies of developing and maintaining high-quality software.

00:24:37.110 This point is essential because others need to learn from your insights into ensuring that a codebase remains in a state that both offers developers a rewarding experience and constitutes an excellent example supporting its users.

00:25:01.180 Now that I've taken you on this brief hypothetical journey, I hope we can all agree that we do not wish to be that developer who feels compelled to apologize to former colleagues for the state of the codebase.

00:25:28.220 So, how can we prevent that scenario? My answer is twofold: firstly, be more disciplined, and secondly, become more persuasive. I will leave you with some references and note that I will make these slides available before the end of the day.

00:25:54.790 Thank you for your attention, and I hope you enjoy the rest of the conference.

RubyConf AU 2019