Practicing what you preach – coding and making bread

Isn’t it hard to practice what you preach? I’ve always heard that the best psychologists are those who are in therapy. Why is that? Whatever the reason is, I’m sure they understand the perspectives of both the doctor and the patient better.

My primary profession is that of an agile coach and trainer. I work with small and large teams of software engineers as well as organizational leaders to be more lean and agile in their product creation and delivery. It’s interesting work because as I a move from company to company I am exposed to varying culture, people, places, processes and products. For someone like me, it is a fortunate place to be. I thrive on variety and changing environments. When I’m home, I work on my family and my own projects. I’m lucky to have a decent work-life balance.

Over the last couple of years, I picked up the ability to do some programming. This happened out of necessity. My childhood friend Curt and I were in the midst of hiring a small offshore team to build our product called Rentific, an online rent-payment platform focused on private landlords and renters. Curt and I have worked together since we were small boys. Our first projects consisted of weather balloons, a flying-wing aircraft with a 28′ wingspan, and various customized rocket launchers. We were nerds and for the most part still are. Fast-forward 25 years, and we were struggling with outsourcing our product development for a number of reasons.

Rentific is a product we dreamed up, because I owned more than a half dozen rental properties and couldn’t believe I was receiving paper checks. Curt and I both recognized the market opportunity, and decided to do something about it.

The first challenge we faced with Rentific was that we were self-funding the project. Since we didn’t have endless financial resources, we knew our ability to sustain an outsourcing approach was very limited.

The second challenge was that we didn’t know how to build the product ourselves, and therefore felt removed from the process. This product detachment constrained us from thinking innovatively. We didn’t understand the nuances of the product, nor could we imagine some of the specific business rules that might be needed to make our product better. We were working from a list of features, some wireframes and looking at our competition.

Providing work to our outsourced team was slow and arduous. Curt and I picked the features we thought were important and competitive, and we gave it to the team to build. Features were turned out very slowly due to our limited resources. The feedback loop between what they built and our vision was too long due to time differences, poor availability and lack of vision on our parts.

After four or five months, our funds started drying up and our product was not progressing as we hoped. It was time for us to start learning some programming. We realized that if there was going to be any chance of success, we needed to build it ourselves. We needed to get intimate with our own product.

Curt and I had built web sites using common web programming tools like CSS and JavaScripting. Rentific would require more than this in order for it to be robust and secure. Our offshore team used Java and MySQL, and so we started there. Unfortunately, I knew the learning curve for Java was too high for us to be productive, so we decided to go down a different route.

We stumbled upon ColdFusion. It’s not the sexiest approach, it is not popular, and is outdated for the most part. All of the negatives aside, we knew we could learn it fast and produce a product quickly. Within three months we had something and the two of us were neck-deep in our own code. It was wonderful.

By building it ourselves, we learned more about our product. It became clear that we would have never been able to communicate our needs to our offshore team, because they didn’t know how to elicit those needs, nor did we know enough about our product at that point. Our offshore team members were task takers and not collectively owning the product as one would want in a real agile team.

Our product development approach was agile and lean. We prioritized the work, built it, tested it and got feedback from our own beta users. As Rentific moved from concept to the first versions of the product, Curt and I continued our professional careers, he as a doctor in Charleston, SC, and I as an agile coach and trainer working in the US and occasionally in Europe.

After nearly two solid years of building our product incrementally, I’ve become quite a decent developer. This wasn’t something I set out to do; it happened because that’s what needed to happen to build our product. We even began incorporating more modern language choices and practices as we continue to sunset ColdFusion.

As an agile coach, I am always working with programmers. My team-level engagements are often focused on helping them understand pair programming, testing, time management, making work small and simple, integration practices, collaboration, transparency in communication, and lots of other agile practices. But, despite my ability to be lean and agile, when it came to applying those practices to Rentific, it wasn’t without its own set of challenges.

One of the practices I struggle with is keeping my work small and simple. If you build web or software products, you’ll probably relate to this. Occasionally, while in the middle of coding, you feel like you can continue working for hours and hours without stopping. When this happens, I don’t want to eat or use the bathroom, and I think if I get up and stop my train of thought, I am screwed. I’ll go so far as fantasizing about having an assistant who can get me food or make calls for me. If I don’t drink a lot of water I reason, then I can probably reduce the need for bathroom breaks. It’s sort of a crazy way to think.

Trying to think through all of the permutations of a test case can require a lot of mental focus, especially when working alone. I often have no one to bounce ideas off of because my schedule doesn’t always match Curt’s. The worst situation is always late in the afternoon, just before dinner. All of a sudden it’s 5:30, and I’ll realize I need to crank the speed up so I can finish everything before dinner in an hour or two.

The start-stop behavior puts a lot of pressure on me, and I rush. When I get back to my code later, I have to remember where I was, and many times where I was wasn’t a pretty place. I am experiencing firsthand, one of the pitfalls I help teams try to avoid… keep it small and simple. Work on small testable pieces, and combine them later.

A couple of months ago, I had a revelation that helped me become a better coach. I was having a glass of wine and enjoying a simple Italian dinner that I cooked, with my family. The sauce and pasta was all made from scratch. Feeling all those Italian roots within myself, I thought, wouldn’t it be great to compliment this meal with freshly made Italian bread too?

So, I whipped out my phone, poured another glass of red wine, and looked up an Italian sesame-seed bread recipe. After a couple of minutes, I found the one that sounded the best. It took me two minutes to get out the ingredients, the bowls, and utensils.

This particular recipe called for several periods of preparation followed by 90 minutes of waiting for dough to rise. It took me less than five minutes to prepare the starter dough, which is used to kick-start the rest of the dough later. After it is prepared, it is left overnight in a covered bowl. It was about 11:00 PM when I started and by 11:05 PM I was done. Now what should I do? The answer was Rentific of course.

The starter dough had to sit in a bowl overnight. I couldn’t do anything else with it until the morning. Starting Rentific at just after 11:00 at night meant I only had an hour of work before I start getting too tired to be productive. A natural limit would prevent me from working all night. This was good.

I was getting ready to start a new piece of functionality for verifying a person’s identity using a third-party authentication API. This piece of functionality will be used to help prevent fraudulent use on our site. I never built anything like this before, but I have certainly used applications that employed similar functionality

Having only one hour of work left for the evening, forced me to approach the module with a small goal in mind. Like the starter dough, I was going to create a piece of the recipe and put it aside for the evening. I set off to create the xml parser and functions needed to handle the web service and data locally.

The next morning, I woke up, checked the dough and started the next phase of the recipe. I also knew that I’d be picking up where I left off on Rentific. The simple module I built the previous night was the perfect size for me to code, test, and walk away.

Using the starter dough I began preparing the larger batch of dough. After combining the simple ingredients and mixing it into the starter dough, my final batch was ready to be set aside. It had to rise in a bowl for about 90 minutes and then be removed, kneaded further and put back in for another 90 minutes.

It was important to stay within the 90-minute time frame in order to keep the dough progressing successfully. I worked on Rentific during the two 90 minute periods needed for the dough to rise. In the first 90-minute session, I struggled a little to find something to work on and finish before my next break.

During the second 90-minute block, it was easier for me to pick up another unit of work and finish it in time. I was forced to get into the practice of working in smaller batches. My experiment was a success. Not only did I produce small pieces of working functionality that could be tied right into the rest of Rentific, I also produced 3 loaves of crusty sesame seed Italian bread.

This exercise got me to think outside the box and provided further insight into a practice I wholly believe in, but until now didn’t have solid personal experience to support it. After my coding and baking experiment, I continued to work this way. It has helped me to focus constantly on producing a minimal viable product (MVP) with everything I work on.

Importantly, focusing primarily on creating small pieces of a product in short periods of time is complimented by doing some other creative activity during breaks. I often see this with product development teams here in NYC, where developers will take breaks with one another and sit down for an activity. They play games of speed chess or Ping-Pong. This break gives them the mental space from their difficult and complex tasks, providing just enough distance from their development work to give them a moment to breathe. When they get back into their work, they are refreshed and energized.

In order to be successful at what you do, take breaks, exercise different parts of your brain, and work towards small goals. Try mixing dough with your left hand if you’re right handed. You might find this small physical challenge helps you be more creative. Essentially, do anything you can to be creative while working, it will make the whole experience better.

As an agile coach, I’ve been preaching this all along, but until I had to force myself into taking breaks and time-boxing my own development work, it didn’t become something I practiced fully.

Here’s the recipe that will make you be a better developer and agile coach!

– by Pat Guariglia


untitled
photo credit: King Arthur Flour

http://www.kingarthurflour.com/recipes/italian-bread-101-recipe

Leave A Reply

Your email address will not be published. Required fields are marked *

7 + 5 =