Anti patterns in software development processes
It is not just in the code itself we will have to look out for anti patterns. There is also all sorts of stuff going wrong in our development processes itself.
If you are interested in reading more about other areas of software development, feel free to follow that link
Let’s find some clarity by listing some of the anti patterns I have witnessed in my time in software teams.
Anti patterns
Not invented here syndrome
Right at the beginning, an absolute all time favourite of mine. This anti pattern describes the habit of doing everything yourself. If it hasn’t come out of the fingers of the software team, it cannot be good.
Not reusing what other brilliant minds have thought of, is one of the worst ideas a software product can have. I am not saying copy-and-pasting (see anti patterns in software development), not at all. But before starting to code, let’s have a look what library, what dependency or what framework is out there.
Otherwise you will make your efforts unnecessary expensive, you will need to put way more effort in to finish something in good quality. Whenever I see use cases of common frameworks I ask for it, and if the answer is: “we have our own framework for that” or something similar? I recommend running or being well aware, what you are getting yourself into.
Hoarders
Hoarders are coders that display work behaviour in which they repeatedly work privately. They hoard all their work in progress and deliver that one big pull request bomb at the end of the iteration.
It’s not unprecedented for software engineers to wait until their work is done before they share it. There are bounty of reasons why this may be the case: fear of having others judge the work in advance, fear of others taking thoughts, or a desire to make the entire handle appear easy, to name some. Some simply did not train the habit of publishing early and often and working transparently.
The heart of the problem is this: the more an individual saves up their work, the less they collaborate with others. Working alone is inalienably more hazardous than working with others. And software development is definitely a team exercise. Don’t be the one person in your sports team that never passes on the ball.
Hero saves the day
It is release day, the code freeze is still in action, everything seems good to go. But that one engineer, maybe the most seasoned one, the one who knows every single corner of the code base, finds a bug and also provides the fix very quickly. Cherry-picks and rebases some things around and saves the day at the last minute.
Sound familiar? It also often has a very reoccurring tendency, that fixing of other people’s work at the last minute. I know, good catch, better save. But you have to keep in mind what kind of unhealthy dynamics heroing creates in a team, not even speaking about a habit creeping in for the others where it encourages faulty software engineering. Because, our hero is here.
Without knowing it the heroes foster a culture of laziness, because everyone knows she will save the day. Have you read about Brent in The Phoenix Project? Recommended read. Because additionally, you start working badly on your truck number as well by allowing for heroism.
Byte nudging
I have thought long about how to name that one, and I feel byte nudging fits it quite well. It is when you have that problem to solve and it looks to you like a riddle. Because maybe things are not completely clear, or the codebase is tough to understand, the task at hand seems blurry so you start to do a bit here and there, but everything starts to look the same and there is just no progress.
Also it comes with a too narrow focus on things. An engineer looking at a certain area of the code base, not getting the bigger picture anymore and only making tiny changes here and there. The missing context of the problem and the will not to appear lazy, then leads to byte nudging.
Bumble Bee
An engineer who has her finger all over the code base but never digs into heavier problems. A fix here, a tiny change there, another small issue here. Basically like a bumble bee flying over all sorts of blossoms, that engineer lifts everything but nothing heavy.
While that has some very healthy aspects to it, tiny units of change, it also can show very problematic over a longer period of time. That engineer will not find the feeling of accomplishment as her colleagues that wrote complete components or created major changes. This habit will make sure, that this engineer will not get a sense of ownership of anything in the code base.
Endless refactor
We’ve all been there. We have learned that legacy refactoring in small amounts is healthy. I am not getting into the argument that this is not really what refactoring was about in the first place (hello TDD, looking at you).
Often when somebody engages in refactoring, especially planned bits like complete modules or components scope can creep into massive really easily.
Suddenly the refactoring becomes big, or maybe even was planned that way? Removing that old outdated library which was surprisingly weirdly entangled with the complete codebase turns out to be way more bigger than expected. A parallel universe of branches, merges and rebases emerges.
Only very few people know how to navigate that universe and to be honest, rather be done with it than actually finish it. I feel you. This is not what refactoring is about. This is not how modernisation should look like as well.
Just one more thing (The Steve Jobs nobody is waiting for)
Right before the deadline. The release is done, about to be published. And here we go: “I feel there is just one more thing missing”.
From poor planning, bad estimates, too much work in progress, last minute requests, opinionated feedback, people feeling left out to simply not respecting the effort that has gone into making something complete this pattern has many faces.
It can be PR, a release, a simple issue in a ticket system. Often displayed when the value of “getting something done” is not well understood. It is a gateway to reducing quality and leads to all sorts of bad anti-patterns. Skipping testing, rubber stamp reviews (not really looking at it, just approving so it is out of the way), and others.
Create a habit where you keep the timelines. One more thing? Perfect, there is always a next time.
Wave through
We all know those colleagues who always give you pull request approvals, right? Ever wondered if they actually gave it a thorough review? This anti pattern describes exactly that bad practice. Waving pull requests through without providing any useful feedback or putting work in at all.
Just browsing over it should not cut it. That can be seen very often when the person who provided the pull request has some level of seniority while the reviewer does not and therefore trusts that “everything will be fine anyway”. Or “who am I to challenge”. Another possibility would be, that the reviewer just does not value a good code review.
Whatever the reason, a code review is a very good built in mechanism for collaboration, learning, exchange, mentorship and last but not least quality control. Waving through sacrifices all those benefits.
Judge Dredd
Do you remember that comic/movie? Judge Dredd is police, judge and hangman in one person. That is basically what this pattern is about. Having the hero saving the da in mind, this can be closely related to it.
Some code appears shortly before a release is due, a pull request shows up and get reviewed and merged by the submitter. Then maybe put directly into a release and moved on. Now that code is headed into production.
No one reviewed that work, no one checked it, learned from it. If code is worth being put in the main branch, it is worth having a review on it.
Long running pull requests
A pull request that does not close in a short amount in time when requested a review always means there is trouble. Either your complete pipeline is jammed and nobody has time, or there are uncertainties or disagreements about what should have happened to the code in the first place.
Often people engage in pull requests quite frequently, you will see a couple of comments and then suddenly nothing. And the pull request just idles around. It will become harder and harder to integrate the changes, the older the pull request gets. Especially as we aim for a fast pace in all aspects, that shows that there is communication to be done.
While I hope those patterns are all very unfamiliar to you I also hope they give you a pointer in the right direction.
fyi: I once again linked The Phoenix Project with an Amazon affiliate link.
