Lessons from Pragmatic Programmer: Software Entropy

After thinking about an early chapter in Pragmatic Programmer (20th Anniversary Edition!) I have a revelation on the Software Entropy chapter.

Go over a quick overview of the chapter and share my view on software entropy, which is bad code.

I talk about how bad code can spread and also solutions one can take to prevent more bad code.

This article will take you about two minutes to read.

source and more information

Introduction

The chapter discusses how broken windows, left unfixed, will just create more broken windows in the system.

Teammates see these and think they’re part of the feature. Old feature modules that aren’t depreciated.

I see another aspect to this “broken windows analogy”: broken windows can also mean bad code

Bad Code

Basically, my take away from the chapter is: bad code begets more bad code.

In any project, bad code slips in for a variety of reasons. Deadlines (common), junior member of the team wrote the solution the first time, solution not re-factored, etc.

The Spread

The problem with bad code is starts to spread. It grows in subtle ways:

• The new person on the team is looking for an example and uses the bad code as template for their solution.
• The old excuse worked last time, why not this time?
• “If it ain’t broke, don’t fix it!”
• Honestly, if you’re not looking at your old code and cringing, then you’re not improving as a developer.

There are more ways bad code can spread than listed.

Stopping Bad Code

In a way, be on the lookout for bad code. Only you can stop bad code from spreading in the code base!

Ideas to stop or reduce bad code:

• If you’re the senior team member and see bad code, set an example. If there’s a common pattern of bad code, document a general solution for others to follow instead of the one set by the bad code. (While you’re at it, leave a comment on those examples to look at your document.)
• If you’re always crunched for the deadline, commit to less and spend more time refactoring your solution before submitting for completion. Consider this to be a 1% improvement on the code base and on you: as you can write the solution better and faster next time!
• If you’re a junior person, reach out to senior team members for guidance before, during, and after working on the solution.
• Likewise, if you’re a senior person seeing a junior person tackling work that is above their experience level, reach out and give help before, during, and after their story.
• Bring up what you see as bad code and share solutions in a staff meeting. Does everyone have the same definition of “bad”? What do others see as solutions as well?

There are more ways than this list. The most important is to take a stand in an appropriate way.

Conclusion

This chapter in Pragmatic Programmer is short and early in the book. I overlooked the chapter as was speaking about broken windows, which is an analogy of the problem I see: bad code.

When I think examples of bad code, it hits this concept of software entropy well, causing me to think of more areas where the problem spreads.

At the same time, by taking an appropriate approach to bad code, you can start to limit it and create a system you and your team members will love using more.