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.
