It’s easy to over assess a problem. Last week, our dryer broke. Erin discovered the problem and started searching the Internet for answers. Most of the recommendations were to check various fuses and relays. Unfortunately, all of these parts are inside under the drum and required disassembling the dryer. After doing the procedure twice, I can complete the task in 5 minutes. The first time, it took awhile to get through and I even got a nasty cut in the process. Eventually, I decided the timer was busted because it was acting weird when the knob turned and I could make the dryer run when holding the start button while jiggling the timer. So, I ordered a new one for $40.
Also last week, a client complained that a date on their rental application was coming in as YYYY-MM-DD instead of MM/DD/YYYY. Their first thought was that we were converting it to that. I didn’t think we were, so I poured through the code looking for any sign that we were converting the date. This was a long process since I hadn’t worked on the code in over a year. I added some code to convert the date to the proper format, something that should probably have been there in the first place, even though some of my testing showed that the dates were coming in correctly. That cost about $60.
Once the timer came in, I installed it and everything seemed to work. Later, Erin tried to start a load and the dryer didn’t turn on. I was flummoxed. Erin then had an epiphany and asked, “Could the knob be broken?”
After I added the date conversion code, I took a second to look at the HTML for the
input. It turns out, I had used
type="date", which Google Chrome populates as YYYY-MM-DD.
In both cases, the fix was the UI. The knob on the dryer was around $10. I probably wouldn’t have billed for changing the field to
type="text" to allow the user to enter the date as we asked for it (ignoring that the conversion code was good to have anyway).
So, when you’re faced with a seemingly complex problem, don’t forget to check the UI.