Seemingly simple software and app development projects often pose many unexplored questions and problems. Even the most basic software solutions may have dozens of decisions behind them. In this post, we’ll take you through an example of how an "easy" task actually plays out in the development world.
Have you ever been in a meeting discussing project requirements when someone—could be the client or a salesperson—chimes in with, "Well that doesn’t sound too difficult," or "That should be easy," or "That seems simple, it shouldn’t take very long, right?" We’ve all heard those dreaded words and just wanted to cry out, "It ISN'T as simple as it seems and it WILL be difficult to implement—even though we’ve done it before!"
These statements are heard quite often in software development; but why? Why do people assume that programming tasks are simple? Perhaps it is because we take for granted the myriad of decisions our brains have been trained to make over years of learning and interacting with the world. Perhaps it is because the client’s internal vision of the application or feature is very broad and high level and they haven’t really taken the time look at it in sufficient detail. Maybe it is because hardware is so cheap (you can get a decent laptop for $200 or 128GB USB drive for about $60) and that makes it difficult to understand why the software is so expensive.
So, is there a real world example that would help to inform non-developers and give them a new perspective on just how involved a so-called "simple idea" can be?
That question got us thinking. What if we were to present the workflow of a simple activity, something most of us do every day without really giving it much thought, through the lens of a software developer? Let’s say the activity was putting on and tying your shoes, and our software developer has been charged with writing an application to handle this deceptively simple and routine task.
Note: the requirements for this application assume that the shoes fall outside the general category of "slip-ons" which may include but are not limited to: flip-flops, flats, jellies, loafers, boat shoes, moccasins, pumps, Cowboy boots, clogs, Crocs, mules, and glass or bunny slippers.
Application Workflow for Putting On and Tying Shoes:
Wow, I Never Thought of it Like That!
While this example may appear extreme, it illustrates the type of detail, thoughtfulness, and quality each facet of your project requires. All of these conditions must be considered, defined, refined, and implemented in the code and the design—and we didn’t even cover how to tie the shoe!