My freshman year of college, I took a Systems Analysis class. It was by far my favorite class. The college I was attending did not have a Computer Science program (it was 2000, computers were still a novelty apparently), but was in the process of creating one. So I majored in Political Science and took the two “technology” courses available to freshmen. One was “Computer Skills”, which really should have been called: “Learn the Office Suite¹.” The other was Systems Analysis.
When I look back on all the computer science courses I took, it’s really hard to pinpoint any single lesson I learned from them. I’m sure I learned a lot and still rely on that knowledge today, but nothing sticks out in my memory the way that Systems Analysis class does.
There’s one lesson in particular that I reflect on a lot. It’s a lesson I don’t think I truly understood how to apply until later in my career, but one that I now think about every time a new request comes across my “desk.”
The Midterm
For the midterm, we were split into groups and the professor give us a business problem to analyze. The assignment outline was straightforward: 1) define the problem, 2) develop a solution, 3) implement a proof of concept. The last instruction of the outline was:
“Your task is to develop the quickest to implement, least disruptive, and most cost-effective system to solve the businesses problem. You will be graded on these three criteria.”
Every group failed the midterm.
The Problem
The business was an automotive scrap yard, “Buddy’s Scrap Yard” (I don’t remember for sure if that was the name, but it sounds good). Buddy kept his inventory in a large paper ledger. Each line in the ledger was a part in his multi-acre yard. When a new part came in, he updated the count in the ledger or added a new line. When a part when out, he did the same. Buddy didn’t use or have a business or personal computer, everything was on paper.
Once a month, Buddy had a “Pick your own part” day. People would be able to wander around the scrap yard and pick any part they wanted and pay a reduced rate for the part. Because the reduced price, these “Pick you own” days were very popular and accounted for a sizable portion of Buddy’s income. But with the increased volume, Buddy was unable to update the inventory ledger in real-time and his ledger was always out-of-date. He was losing regular business because he was never able to be certain if he had a part he promised a customer.
The Wrong Solution
My group’s solution was to develop a software inventory management system. Each part would have a barcode. Parts could be indexed by multiple facets. The yard would be split up into zones so that each part was easy to find. For the “Pick your own part” days, additional staff would be hired to help customers find parts, pick them from the yard zone and scan the parts during checkout to update the inventory. We built a prototype in Microsoft Access. All of the other teams proposed a similar solution.
Least Disruptive
We had all missed the most important part of the assignment outline: “least disruptive.” Everyone in the class was interested in technology. Almost everyone knew how to code. Everyone loved computers. We all read the problem and immediately thought: “How can software solve this problem?” None of us considered how disruptive a software solution would be to a company that only used paper and didn’t even own a computer. Sometimes the unintended cost of the best solution makes it the wrong solution.
It was a strong lesson in thinking critically not only about the problem but also your solution. It’s something I try to remind myself every time I build something new. Am I solving the right problem? Do I understand what the problem is? Have I considered what my solution will cost the user? Is my solution the least disruptive to the current system?
It’s hard to keep Buddy in mind when developing a solution. Throughout my career, I have often forgotten this lesson. I’ve built the solution that I wanted, the one I found interesting or mentally challenging, instead of the least disruptive solution. It unfailingly creates more problems, more work, takes more time, and leads to more burnout.
The “Right” Solution
The solution our professor proposed was maddeningly simple. Paper tags, a card catalog, and Buddy’s existing ledger. A card with a unique number would be affixed to each part. An index card with that number and a location of the part in the yard would be filed in a card catalog and an entry would be added to the ledger with the number a description of the part. Every time a part was taken out of the yard, the index card would be taken out of the catalog. On “Pick your part” days, the tags would be collected throughout the day and Buddy would update the card catalog at the end of the day. The least disruptive system.
¹ When we got to the FrontPage part of Office, I got a D on my website design project because I refused to build it in FrontPage. I wrote it in HTML like any sane person. I was furious. I went to my professor and protested. He said, “you didn’t do the assignment.” When I asked how he knew I didn’t use FrontPage, he said: “The website looks too good. You can’t do that in FrontPage.” Well worth the D.
Top comments (0)