The National Park Rule – Cisco Blogs

Software Development Straight Talk Series

In this new series, I will introduce popular and not so popular concepts in the software engineering world. In each article, I will be introducing a concept, its goals, the mechanics of the concept, and then onto a discussion of pros and cons. You can think of these articles as a discussion with fellow engineers over pizza and beer. There is no right or wrong answer, only a discussion of the concept and its benefits, disadvantages, and pitfalls. I will be bringing to the conversation 25 years of professional software development along with an open mind. I ask in return that you bring an open mind and help me carry the conversation forward in the chat section. In this series I will not pass final judgment, nor offer a single solution as I believe that circumstances of each environment can affect how a concept is applied. Let us move onto our first concept.

This concept is not widely known by this name from my experience. The National Park Rule concept was taught to me when I worked for a small company in Ohio by a group of very intelligent engineers. If you are a frequent visitor to the national parks, you may know this rule. So, what is this rule?

The rule can be simply stated as “you should leave a park cleaner than how you found it.” Of course, we live in a time where littering is extremely frowned upon, but we must all face the fact that the wind or even a loose zipper could lead to accidental littering. The National Park Rule suggests that you take a spare bag to pick up litter to leave the park a little cleaner.

How does this apply to software development? Software projects are like the national parks, they have signs, rules, new and repeat visitors, litter, and even their own critters. A mature team will have: read me file(s), change log file(s), code, code comments, diagrams, API docs, etc. The National Park Rule can be applied to all these examples to fix grammar, add or clarify comments, clarify API documentation, add additional unit tests, etc.

Now that I have introduced the concept, what are some of the pros and cons of the application of the rule? How can the rule be applied to benefit a project? How can the rule be applied to hinder or derail a project? Let us cover some of these.

Pro: We have all modified code and found comments that are not clear or forgot a step, correcting those comments benefit the current maintainer, new visitors in the future, and someone reviewing the code. You do code reviews, correct? Remember that in six months, even the smartest of us may not remember every detail of an algorithm.  Having those comments will save us some time and stress in a time of pressure.

Con: A developer may take it upon themselves to perform a full rewrite of code in the name of The National Park Rule. This was not what the rule is for, it is for minor cleanup. In this case, developers should work with their manager/scrum master to plan for a rewrite.

Pro: Adding additional unit tests can reduce bugs in the future. It is inevitable that code must be updated and without unit tests, we are relying on developers and testers to remember all use cases. Adding additional tests will provide insurance for when those people with all the knowledge move on from the current project.

Con: Some developers may take this rule so seriously they go looking for issues like missing comments, unit tests, etc. and get distracted from the real reason for being in the module. They should be reminded that to limit the amount of cleanup and create an enhancement for further cleanup.

Challenge: In some projects, time must be accounted for and a rule that identifies that persons should perform cleanup may eat into the limited amount of time that a project should be worked on. Developers should make sure that their project can properly support minor cleanups like this. An example would be an Agile project, the scrum master may prefer cleanup actions get converted to user stories that are planned for a future sprint.

Let’s continue the discussion below in the chat section. What do you think, is The National Park Rule something you could apply to your projects? Is it a rule you already have, maybe named something else? What are the pros, cons, and/or challenges you see? I look forward to hearing your thoughts.

Future topics in no particular order that I may cover are:

• Dust Bunnies and Technical Debt
• “Modern Languages”
• To Abstract or not to Abstract
• Cloud Native
• Gone Fishing in a Data Lake
• Agile Capacity Planning
• Organizing Large Projects
• Iterative Development
• To Rewrite or not to Rewrite

Follow along with my blogs and future discussions on blogs.cisco.com/customerexperience.

Photo by Stephanie Bergeron

Share: