People like hot dogs until they see how it's made. Most people don't ask, because they don't want to know and keep eating hot dogs. In software, sometimes we have to ask. It's not just about solving problems, but because what scares some programmers is the knowledge that their car's software might be little more than the equivalent of driving duct-taped toothpicks down the highway at 70MPH. Our entire field is bad at what we do.

Brett worked as a system analyst for a medical research institution, MedStitute. MedStitute used proprietary software for data storage and analysis, called MedTech. Doctors and researchers like MedTech's results, but Brett his co-worker Tyree- know how it's made.

The software has no backend access, and all software development happens in a "click-to-program" GUI. The GUI looks like it was built from someone who learned to code by copy/pasting from 1990s era websites, watching ten minutes of Jurassic Park, and searching StackOverflow until something compiled. The "language" shows the same careful design philosophy. Every if must have an else. Some modules use booleans, some return an empty string to represent false values. Documentation is unclear about which situation is which. Essentially, every if statement becomes three statements.

Brett needed to launch a new study. A study depends on some basic set of statistics and groups patients based on a randomized variable. Brett looked through the list of variables he could randomize on, and the one he wanted was missing. Brett assumed he made a mistake, and went back a few screens to check the name, copying it down for reference. He went back to the list of randomizable variables. It wasn't there. He looked closer at the list. He noticed that the list of randomized variables only included data from multiple-choice fields. The field he wanted to randomize on was based on a calculated field.

Brett knew that Tyree had worked on another project that randomized on a calculated field, so he messaged Tyree on Slack. "How did you code this random variable? In Medtech it won't let you?"

"I'm on a conference call, let me call you afterward," Tyree wrote.

A few minutes later, Tyree called Brett.

"What you have to do is start with two fields. Let's call it $variable_choice, that's a multiple choice question, and $variable_calced that's your calculated field. When you want to create a variable that randomly selects based on your calculated field, you start by telling Medtech that this random variable is based on $variable_choice. Then you delete $variable_choice, and then rename $variable_calced to be $variable_choice."

"Wait, they allow you to do that, but don't allow you to randomize calculated fields any other way? And they don't check?"

"Hopefully, they don't decide to start checking before this project is over," Tyree said.

"This study is supposed to go on for ten years. This project succeeding comes down to them never treating this workaround as a bug?"

"It was the only solution I could find. Let me know if you need anything else?"

Brett wasn't completely satisfied with the hack and went back to the documentation. He found a "better" solution: he could make a read-only multiple-choice field with only one choice, the value of the calculated field, as the default answer. Unfortunately, it was possible that the user would alter the list unintentionally by answering the multiple-choice question before the calculated field was evaluated.

Ultimately, the only choice left to Brett was to take his lunch break, go to the cafeteria, and order two hot dogs.

[Advertisement] Utilize BuildMaster to release your software with confidence, at the pace your business demands. Download today!