Pedaling Through Code

Pedaling Through Code
My brother and myself on our bikes waiting to start the 100-mile day one ride in the MS-150

As the scorching sun of South Texas bore down upon me during the MS-150 ride in April 2023, every turn of the wheel and bead of sweat mirrored the rhythm and challenges I faced in software development. From the subtle rush of the wind to the intricacies of my coding journey, this article unravels the captivating parallels between two seemingly disparate passions. Dive in and join me on this exhilarating ride through code and the countryside.

The Goal

In January 2023, I committed to riding in the MS-150. The MS-150 is a two-day biking event where riders can ride 100-180 miles to raise money for the National Multiple Sclerosis Society. I signed up. I have every intention of signing up again for 2024.

Research and Planning

My experience with bike riding included riding for fun or transportation. My previous bikes were all bought from Academy or similar stores. The most expensive was between $100-$200.

After committing, I knowledge crunched - learning just enough to get started and then delaying whatever decisions I could. Did my experience as a coder affect how I approached leveling up the seriousness of biking riding?

  • I needed a bike and a helmet.
  • I did not need to commit to clipless shoes & pedals, bike shorts, bike jerseys, gloves, bags, sunglasses, or any other purchases I would make over the next four months.
  • I knew I could iterate for more changes as I gained experience and tested the product.

In other words, I needed to choose a foundation and a starting process. When starting a greenfield application:

  • I need to design a theory about how to solve the problem and make a decision about a starting process for how to collaborate.
  • I do not need to commit to a language, a database, an architecture style, a coding style, or many other decisions at the beginning of a project.

The early decisions can all be changed, though some may be more expensive to change than others. Those are the ones that I hope I get right.

🔄
PROCESS NOTES
Delay every decision until the last responsible moment.

Developing

With some research in hand and foundational decisions made, I bought a bike. My initial cost was about $2,000. With a bike in hand, I started training.

I met my brother in the park, with flat pedals and mountain bike tires, for at least a 20-mile paved ride. My fitness level included sporadic yoga, mostly daily walks with the dog, and running once a quarter. The ride lasted 2.5 hours and was maybe 16 miles. I was slow. I was tired. I used positive self-talk to get past every hill. They weren’t hills, more like small climbs. They felt like mountains.

When we returned to the car, my brother said he wouldn’t ride with me again unless I switched out my tires.

The problem

For my current fitness level, riding long distances at a reasonable speed required more effort and strength than I had available.

The constraints

Time

I needed to gain speed while riding quickly to continue training with my brother.

Money

I needed to make changes that were within specific prices

Changeable components that may improve my speed:

  • Me
  • My bike
    • Tires
    • Pedals

From the immediate options that I knew, only the bike components met both constraints - tires or pedals.

I asked if the tires or pedals would result in a better outcome.

In this case, my brother and I are the end user(s). I listed him as an end-user as he was affected.

He said pedals.

🔄
PROCESS NOTES
Which feature has the most value to the end user? Make one change and test it.

Iteration 1

Clipless Pedals

I knew about clipless pedals, and the thought of my feet being locked to the pedals of a bike made me nervous. Why are they called clipless when I feel like I’m clipping in my feet? When I was young, I rode a bike everywhere without a helmet or gear, most of the time not holding the handlebars. I rode to the store, bought a hot dog, and rode back while eating the hot dog. Now, I am just as clumsy as I was then and am slower to repair. If I fall, I will probably still feel that fall two to three years later. My hands stay on the handlebars. I don’t feel the same self-assurance in keeping the bike upright and straight. Locking my feet onto the pedals - I see myself skidding along the payment, the bike on top of me.

In coding, I worry about leaving behind code others can’t figure out and maintain. I worry about binding myself and my preferences too tightly to the code and creating code unmaintainable by anyone other than myself. We don’t write code for the computer. We write code for other developers. The audience in coding is just as subjective as the audience in fiction writing. How do we ensure that we convey the story?

As with any new adventure, I went online and researched. I found pedals and shoes that fit within my budget. I went to a local bike shop and asked about installing pedals. They walked me through the process. Installing the pedals and attaching the cleats was the easy part.

The advice online for learning how to clip in and clip out was to practice in the grass first. I took my bike to my front yard. I started practicing. I failed to calculate the distance between the rose bushes and myself correctly. I ended up with a few bruises. The bike doesn’t move well on grass. It made the whole process significantly harder. Once I was on the street, the bike moved, and clipping in and out was fine.

🔄
PROCESS NOTES
Do things the hard way until the hard way is comfortable. Don’t improve a process until the process is deeply known.

A side note on copying/pasting while coding

I do copy and paste when coding. I don’t copy and paste when learning a new library, framework, or language. Both copy and pasting and typing come with inherent risks. Copy/Pasting - I might miss something that needs to be changed or deleted. When copying/pasting, I must read through every line. Typing - I run the risk of typos. Some typos can equal actual code that can be deviously challenging to spot or sort out.

Iteration 2

Cycling Shorts

Years ago, I was being silly and fell. The fall resulted in an injury to my coccyx. Today, I am mostly fine - the injury still becomes inflamed sometimes. Especially when I’m not active or, as I discovered, I spend 2+ hours on a bicycle. So, biking shorts. I wasn’t sold on the concept, so I bought a pair from a discount sporting goods shop for $15.00. We can call them prototype cycling shorts. I like pockets, so I typically wear my hiking pants over them.

Buying cheap cycling shorts was a mistake. I think seasoned cyclists know that it is a mistake. When I talked to a few on one of the rides, they commented - yeah, don’t ever buy cheap shorts.

I didn’t discover the mistake until I rode my first group-supported ride. It was my first ride, and I chose the middle option. The options were a 20-mile ride, a 40-mile ride, a 60-mile ride, and a 100-mile ride. I decided on the 40-mile ride. The ride had three stops. I finished, it was exciting.

When I arrived home, I went to take off the bike shorts, and I had to peel them off. It was an unpleasant experience.

I did the research and spent money on another pair of shorts. They were worth the money.

🔄
PROCESS NOTES
Sometimes building/buying a cheap prototype is necessary to understand what is needed. Sometimes, a theory can't be proven false without having a working prototype.

Iteration 3

Tires

When I purchased the bike, I knew I would need to replace the tires. I was buying a bike with mountain bike tires and required hybrid or road tires. The tires are where my lack of knowledge ended up with the most significant setbacks and frustration. There were unknown unknowns for me, and I trusted the wrong expert.

The frame I bought would support 650b or 700c tires. The tires were quick-release. The rims were 650b. I still don’t understand this next part. I still need to do more research. Buying 700c tires and rims requires a different crank and cassette. Ultimately, changing the tires for 700c was priced out of what I had budgeted.

I discussed the options and ended up with 650b tires. This was the one part that was fully described with accuracy for me. I had a choice of 650b tires. The bike expert told me going from my tires to set A was going from a 2 to a 10. Set A to Set B was maybe a 10 to 11. He also said those numbers were completely random and possibly not linear.

Going from my tires to set A was a huge difference, a big enough difference that I don’t know if I want more modifications or a road bike instead of a touring bike.

🔄
PROCESS NOTES
Reaching out and talking to experts when faced with a lack of knowledge is one way to close a gap. Finding experts to trust can be challenging when one’s knowledge is minimal.

Pivoting in a project is a perfectly good solution to the problem. I prefer to pivot when I know the pivot will be successful, and I didn’t know how successful the pivot was going to be until I was in production.

Retrospective

Looking back, I didn’t understand the problem space enough to buy a bike. I went to experts who I expected to guide me through the problem space. The experts were not prepared for this assignment. I had a brand in mind, and they sold the brand. They knew what I wanted to use the bike for. I wanted a touring bike for comfort and endurance. The model had mountain bike tires. I inquired about being able to switch the tires. I was not precise with the question. I did not ask about the difficulty or money in changing the tires. Communication is difficult.

Is my bike a prototype? Did not understanding the problem space cost me?

My bike was a prototype for the MS-150. It isn’t a prototype moving forward. The bike has proved itself.

Not understanding the problem space did cost me. Some money, some pain. I have some more knowledge and will continue to deepen my knowledge. Deepening knowledge is a life-long journey because no subject has been fully explored. The world is still so mysterious.

That is coding, though, or at least product development. Devise a hypothesis or theory. Build or buy something that supports the hypothesis or theory. Evaluate and adjust. See the footer for process diagrams and similarities.


Footer

Scientific Process:

  graph LR;
  A[Observation]-->B[Hypothesis];
  B-->C[Experiment];
  C-->D[Analysis];
  D-->E[Conclusion];
  E-->A;

Lean:

  graph LR;
  A[Plan]-->B[Do];
  B-->C[Check];
  C-->D[Act];
  D-->A;

SDLC:

  graph LR;
  A[Idea]-->B[Planning];
  B-->C[Analysis];
  C-->D[Design];
  D-->E[Implementation];
  E-->F[Testing];
  F-->G[Deployment];
  G-->H[Maintenance];
  H-->A;

Agile:

  graph LR;
  A[Idea]-->B[Backlog];
  B-->C[Sprint Planning];
  C-->D[Sprint Backlog];
  D-->E[Development];
  E-->F[Sprint Review];
  F-->G[Sprint Retrospective];
  G-->B;

The processes use different words. Some decompose the steps further - it all circles back to guiding people through and to empirical reasoning.