{{announcement.body}}
{{announcement.title}}

What Raking Leaves Exposes About Your Development Strategy

DZone 's Guide to

What Raking Leaves Exposes About Your Development Strategy

A Zone Leader applies different approaches for raking leaves towards various development strategies.

· Web Dev Zone ·
Free Resource

In the Midwest, raking leaves is typically something that occurs in the fall and early winter season. For those who tend to not keep up on things, late winter and early spring can result in some leaf-raking exercises.

While talking with Russell (@RussellScheerer) over Slack the other day, he posed the question...

"Does your code reflect your life?"

This made me wonder if a developer's strategy towards development bleeds over into their leaf raking strategy. From my analysis work and history of raking leaves for the better part of thirty years, I feel like there are four classifications when it comes to raking leaves:

  • Let the wind do the job
  • Timebox the effort
  • The 80/20 rule
  • Striving for 100%

In the following article, I am going to point out parallels between raking leaves and a developer's development strategy.

Let Wind Do the Job

The first strategy when it comes to raking leaves is to simply let the wind take care of the problem naturally. This is the least amount of effort by having the individual do nothing at all.

While this approach provides more free time for the individual, it does run the risk of a negative view by neighboring properties. Additionally, based upon the design of the property, there may be no place off property for the leaves to escape, thus leading to more work down the road to not only remove the leaves, but to patch areas damaged by prolonged leaf accumulation.

In Information Technology (IT) this is having the understanding that a problem exists, but doing nothing to address the situation. Of course, this can be okay if another effort of work will make the known issue a non-issue. Perhaps you decide not to rake the leaves because you are about the vacate the premises. Again, not something I would recommend, but an option, nonetheless.

You may also enjoy: Innovate Or Die: The Cost Of Doing Nothing

Time-Box the Effort

The second strategy is to time-box the effort. This is similar to creating a research spike in a development iteration.

Here, the individual will set aside time and focus on raking leaves. This is a common approach, given busy schedules during leaf-raking season, which provides some relief to the leaf situation on the property.

However, like most research spikes, the goal will not be fully recognized - often requiring a second or third-time box effort to be planned.

This is a better approach compared to letting the wind do the job, but the remaining leaves could cause similar issues. Just like in technology, failure to understand something could cause issues to surface during or after the implementation phase.

The 80/20 Rule

Most in technology are familiar with the Pareto principle, which is often referred to as the 80/20 rule. This can easily apply to raking leaves as well.

The goal here is to get the majority of the leaves off the property, then letting nature take care of the rest (either via blowing off property or breaking down naturally during the winter months). In doing so, you avoid spending nearly the same amount of time to gather the last twenty percent of the leaves that was needed to gather the initial eighty percent.

As feature developers, the 80/20 rule allows most of the functionality to be added to an application or service. Over time, the remaining twenty percent is analyzed to determine if the cost to add the functionality is justified by the benefit of having the functionality. While there could be issues with the remaining twenty percent, this is far less than the prior two options.

Striving for 100%

Finally, there is approach where you strive to make sure no leaves remain on your property. This reminds me of a guy named David, who lived across from me several years ago.

Since David was retired, I felt like he made it a personal goal to make sure all of the leaves were removed from his property. So, while working from home on a project with a window view of his property, I would watch him take care of his leaves nearly every day of the week. It did not help that I was more in the "letting the wind do its job" back then. Still, David never mentioned my leaves when we would talk;I just stayed inside while his leaf-removal efforts were underway.

In technology, we realize that striving for 100% is a costly goal. Because making sure everything is handled comes at a price tag that impacts other priorities from being completed. In Dave's case, he could have used this time to play a round of golf — which was truly his passion at this stage of his life. Of course, I do have to wonder if his spouse, Jan, was the Scrum Master setting the priority to make sure no leaves remained on the property before the first practice swing could be administered.

Conclusion

In our town, we simply need to rake our leaves to the edge of the street. Once there, the recommendation is to create a line of leaves that resembles a long triangle-like design.

On what seems like a random day of the week, this loud machine arrives in tow of a big truck. Attached to this loud machine is a huge hose that is operated by a guy who points the end at the leaf pyramids, sucking the leaves into the machine and out of our view.

What takes me a considerable amount of time to prepare is sucked away in a matter of minutes, if not seconds. However, what I noticed is that this leaf collector machine typically only removes about 70 - 80% of the leaves on the street. The rest are left to blow in any direction they desire.

So, in essence, the leaf collector machine and operator have their own strategy in place — probably following the Time Box Effort (the truck always moves at a set speed) to be able to reach the expected homes for a given collection effort.

Have a really great day!

Further Reading

Thinking About Cadence vs. Iterations

The Power of Hindsight in Product Strategy

Topics:
agile adoption ,time box ,pareto ,defect analysis ,leaves ,development strategy ,dev life

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}