Last week I talked about finding the right tool for the job. This week I am going to talk about adapting to unexpected behavior in our processes. I strongly believe the first step to this is avoiding hard set paradigms with regards to software development. Twice, in the last couple of weeks, I have been exposed to opportunities to adapt to unexpected behavior. The first of these opportunities was in my job and is not a success story. I am going to contrast that with an opportunity to adjust in my Senior Project team.
For many years my company has been running a customizable simulation software package that captures a relatively large amount of data. For perspective, approximately 200 GB of data is usually generated for each simulation to capture the data needed for acceptance testing. The unexpected behavior observed was that our simulation tool would seemingly abort towards the later portion of the simulation. All of the great minds got together and decided that the simulation tool must be bad and we needed to yank it out of acceptance testing. It took almost an entire extra sprint to evaluate the code looking for coding errors, memory leaks, and excessive function calls. There were lots of passionate discussions and our processes underwent high scrutiny. But no issues were found. The answer was instead to run several simulations- with each writing out a portion of the data so we could package it all up and give to our customer for their final acceptance testing. Today, about an hour before quitting time, after we had already shipped it to the customer, I realized what the problem was. This release of the simulation tool had several significant requirement changes that pushed the simulation from a 60 year simulation to a 130 year simulation. This was expected. But what had never crossed anyone’s mind through all of our set in place development processes was “can our process for data collection and extraction handle this exponential growth in amount of data?”. We had grown hard set in our beliefs about our simulation tool and how it behaved. We did not adapt well to the unexpected behavior and it cost us a lot of time. Much of which was spent running in circles and even at times throwing blame and questioning capabilities of our entire team.
Opposite to that was the opportunity my Senior Project team had to evaluate and adjust to an unexpected behavior. Before I describe it, I do feel like I need to mention that my partner was the one who caught this and immediately began adapting. For our project we are parsing PDF files for specific wine data. For example, the % alcohol, winery name, type and year of wine, how it was made, etc. Each of these PDFs is like a flyer for each type/year of wine. Across a single winery the format and fonts are usually fairly simple. But from one winery to the next, there is often no similarities. As an example- some may say “ALC 13.0%”, while another winery might say the same thing as “… thirteen percent alcohol by volume”. For most of the customer provided PDFs, extracting the information was easy by taking advantage of the spacing on the PDFs. But for some things this didn’t work. Instead of wrestling through the code to try to force it work, my partner did three things that I was very impressed with: First he stepped back to try to define the problem, then he solicited feedback (from customer, me, internet, etc), and lastly, he looked at possibly using a different approach all together to address the problems.
Maybe the first example feels heavy to me because I lived the experience, where in the second example I was able to observe it. Whatever the reason, I feel like I learned a valuable lesson. I know that there are several factors at play for the different behavior in both of these: the length of time that has been spent locked into a way of thinking, the size of the project, and having the flexibility to be able to try new tools, seek outside help, and adjust. Whatever the differences between them, having had both experiences and reflecting on them has really highlighted the importance of striving to always be adaptable, to be willing to step back and look at a problem from multiple perspectives, and lastly to consider more than just the obvious design elements that might be impacted.
