The five shouts of good programmers
A set of reactions to the most common programming scenarios that tend to turn software projects sour.
Chains and gears (source: Pixabay)
On any given day, a software project fails somewhere in the world. It’s a common thing, so common that people are surprised when software is delivered exactly as expected and when expected. And this isn’t new, it has been happening for decades, according to the widely cited Chaos Report by the Standish Group. Now, in many occasions, everybody will try their best to avoid tragedy, but more often than not corporate politics take precedence over pragmatism, and what could be avoided is simply delayed until it is too late.
In this kind of situation it is common that programmers, being on the front lines of the battle, can see these issues coming before everybody else. However, it is also true that programmers have traditionally lacked the sort of soft skills that are needed to present these problems in a convincing manner, meaning that in many occasions they just keep working on a doomed project.
Learn faster. Dig deeper. See farther.
By observing this pattern again and again, I realized programmers needed a mechanism to push back effectively; this is how I came up with The Five Shouts, a set of reactions to the most common scenarios that tend to turn software projects sour. These “shouts” are metaphorical (e.g., I’m not encouraging people to start screaming at each other!) They’re merely simple phrases you can tell yourself whenever one of the following problematic scenarios surface, enabling you to have the strength to steer a doomed conversation in a positive direction.
So, without further ado, here are The Five Shouts.
1. Don’t repeat yourself!
Imagine you are in a situation where you need to create a particular piece of functionality and there is something similar that already exists. Obviously, the best solution would be to modify the existing functionality to cover the new cases; however, that would require you to test the new and the old scenarios to make sure you didn’t introduce any regression bugs. A project manager willing to bring the dates forward will suggest that you simply duplicate and amend the code, so only the new scenarios need to be tested. This is when you need to use “Don’t Repeat Yourself!”
The main reason is that duplicated code is one of the biggest sources of bugs. When you have two functions or modules that do very similar tasks, and at some point the business rules change, it is very probable that a programmer will remember to update one of the modules, but not the other one, creating a bug. It also hurts code intelligibility. A new programmer encountering duplicated functionality may wonder when each of them is used, or even worse, if both of them are used at all. Creating duplication is just a shortcut that you will end up paying for in the future.
2. No monkey business!
The second scenario involves repetitive tasks. Programmers frequently want to automate these, but managers often don’t provide the resources for investment, instead arguing that “it’s just a few minutes.” What people don’t usually realize is that repetitive tasks are error-prone and tend to grow. Five minutes will turn to 10 minutes, 10 will turn to 15, and so on. Soon enough, people will be banging the keyboard looking like they are doing a lot but not accomplishing anything meaningful, much like a monkey.
This is the moment where programmers need to use “No Monkey Business!” Programmers are there to program, and having them perform thoughtless activities is a waste of their abilities, which in turn leads to demotivation. Besides, automating a task will force you to look at it with a more critical eye, which will reveal flaws in the process that had previously gone unnoticed.
3. Safety first!
Corporations tend to be rather risk averse in the majority of their activities: in advertising, since sending the wrong message can become a PR nightmare; in finance, since poor monetary planning can lead the company to insolvency; in market research, since new products need to be accepted by the public. However, when it comes to technical risk aversion, corporations often have too big of an appetite for risk, presented mostly in the desire to save costs by reducing or eliminating testing activities. Although practices like Test-Driven Development seem to be gaining traction, I still hear all sorts of arguments trying to convince programmers to save time by not writing automated tests: Some say that true programmers who know what they’re doing don’t need tests; some say that tests aren’t delivered to the customer and therefore are not part of the product, which means they can only be done in the programmer’s own personal time. And you’ve probably heard worse yourself.
The truth is that disregarding safety is so common that people don’t realize they are working in an unsafe environment. However, you can find proof of this by analyzing the typical conclusions in a project post-mortem (or retrospective): Failures are usually blamed on things like bad requirements or bad estimations, but never on unsafe environments. People never say “we failed because we worked in an environment which doesn’t prevent mistakes,” which is why we need to use “Safety first!”
4. YAGNI!
Software development is a relatively young profession, at least compared to other forms of engineering. As is often natural, new professionals bring habits from other disciplines into software development, and one of theses habits is to try and predict future needs.
Imagine you are a civil engineer and you are requested to build a two-lane traffic bridge. It may be worth speculating whether, at any point, the bridge will need to have four lanes, because then you can build stronger foundations that will make the expansion easier in the future (admittedly there may be many other aspects to consider here, this is just an example). Following this logic, projects are usually riddled with extra, speculated requirements that nobody has requested. These are added based on the assumption that it is cheaper to do so sooner than later.
The first problem with this argument is that it hasn’t been demonstrated that it is truly cheaper to build something before it is requested, particularly if we use modern, iterative practices. The second problem is that, whenever issues arise with functionality that is not needed, managers often decide not to address them (“nobody is using that, anyway”). This encourages a culture where the code has varying levels of quality, with sections that rot until they become completely unusable. And, worst of all, it decreases the morale of programmers, since there are few things as depressing as working on something that is never going to be used.
It is in this kind of scenario, when requirements are being unnecessarily bloated, that programmers need to use “YAGNI!”, short for “You Ain’t Gonna Need It!”
5. Yes now!
This is my favorite. Programming is a constant adventure. You need to explore code that was probably written years before by a person you never met. This code may have been written under the best or worst of circumstances. You never know what you are going to encounter—could be a piece of art or unworkable garbage. It is just this fun!
Now, if you were a cook and arrived at a mess of a kitchen, probably your first impulse would be to clean up before attempting to do any work. And, as a programmer, that might be your first impulse too when you encounter messy code. But that clean up may not be part of the project plan, and your good intentions may be put aside with a polite, “that’s a great idea, let’s just not do it now.” This is when we need to say “Yes Now!”
A culture where problems are fixed as they appear is one of the most fundamental traits of successful projects. Without this culture, the broken window prophecy kicks in, and programmers simply get used to working with badly-designed code. What’s more, team spirit is hurt, since the distinction between me breaking the code, or the code being already broken, becomes important. “Yes Now!” helps teams focus on ensuring things are right, regardless of who made them wrong in the first place.
One last warning …
The Five Shouts are a useful tool, but like any tool it can be destructive if abused. Since the shouts are used to present opposition when a bad decision is about to be made, they can sometimes lead to conflict. This isn’t necessarily a bad thing, for conflict is sometimes necessary to find the best solution between multiple alternatives. But it does mean that The Five Shouts need to be used with caution.
Homeostatic impulses are a psychological tendency to reject change. When you start using The Five Shouts, you will be attempting to change the way decisions are made, and many people will initially fight this. For this reason, it is best to moderate your shouts initially, and apply them only to the most glaring circumstances. As change is executed, other people will slowly notice the benefits themselves, and you will be able to apply the shouts to more and more scenarios.
Change is hard, particularly when we are fighting against habits that have been with us for decades. Use The Five Shouts wisely, and you will see your code and projects gradually turn for the better.