Software Development is Still Too Complicated

codeIt’s the 21st century and the software development process is way too complicated. It really hasn’t improved all that much in the 35 years I’ve been doing it. Oh sure, we have fancy colorful screens and mobile devices, but at the core of every app (we used to call them programs) is a very simple (and rather limited) set of functions. Seriously, there are millions of implementations, but there just aren’t that many patterns (a more current term for functions). Let’s see if I can prove it to you…
Grab your smart phone and let’s inventory your apps. See how many fit this pattern.
  • They display a “list” of something.
  • They show you a more complete “view” of one thing on the list.
Let’s take an inventory.
Email App: Hmmm, let’s see. List of emails. View of an email. Sure, there are a couple of “actions” you can take, but as you’ll see soon, those are pretty much all the same, too.
Music Player: Yep. List of songs and a view of the current song playing. Oh yeah, the audio coming out of your headphones, isn’t that just a slight twist on a “view”.
Twitter, Facebook, Stocks : This is getting boring. You get the picture.
Go through all your apps and let me know when you find one that doesn’t fit this model.
Now you understand the “presentation” layer. In the old days we called it a “screen”. More recently it’s called the UI, or user interface and today it’s the UX (user experience). All “screens” amount to one of two designs: list or view.
But a list or view of what, exactly? Again it’s simple. Data. And while data can be complex, it’s not complicated. There are only five (that’s right just 5) things you can do with data. And fortunately, there is a term for the first four that programmers (excuse me, developers, software engineers, etc.) have used for years: CRUD. It’s an acronym for Create, Read, Update, & Delete. These all relate to storage of data. One more thing we can do…process the data. In other words, do some calculations, translate it to another language, convert it from an mp3 file into an audio stream, add a Duck Dynasty beard to a photo, etc.
Now back to “actions” that were mentioned earlier. This is where you, the user, interact with the software (and maybe the user is another software application). Again, there are really a fairly small set of actions that exist in our software universe. See if you can recognize these related to a “list”:
  • Filter: works on a list to limit entries on the list. For example: when you type “cute cat videos” into Google, the “list” returned is pretty much filter to the 116,000,000 relevant results.
  • Sort: changes the sequence of the list. For example, you can sort you mail by date or by the from email address.
  • Add: you are creative and are going to use the “C” from CRUD to add a new entry to the list
  • Delete: OK, your creation wasn’t so good or maybe if you delete the bagel from your diet app, it will delete it from your belly, too.
  • View: this one is easy, send me to the “view” for this list entry (the R in CRUD)
  • Categorize: Think folders in email, or subreddits, meals in your food tracker, bookmarks or favorites in your browser
  • Refresh: in case your “list” of tweets is getting stale
  • Copy: Hmmm, maybe. But isn’t “Copy” just a “View” tied to an “Add”
Then there are a actions on the “view”:
  • Update: you changed something and want to save or update (the U in CRUD) some data
  • Delete: this action is shared with the list
  • Add (Copy): again shared with the list.
All these actions are processed with software instructions. So if there are so few, why do we keep writing the same software instructions over and over and over? Maybe it keeps all those programmers, er… software engineers employed. But wouldn’t it be great if they could all be solving new problems, rather than the┬ásame old ones over and over. Instead of a team of 10, 20, or 50 developers, you get real things done with 2 or 3 for most apps. (Sure, I get that the “filter” action of Google is a way more complicated, but the average app doesn’t need that level of filter–and if it does, use Google.)
Enter the software “framework” or “library” or “component” or “tool” or whatever. Valiant efforts are made to try and standardize all this development. But in the desire to maintain ultimate flexibility, the simplification is lost. And sure, using Angular, Knockout, or React are better than cranking out the raw JavaScript, but this is the same argument from the 1960s when programmers decided Fortran and COBOL were “better” than writing “machine code” or assembler. Both true, but both arguments miss the point.
Finally, let’s talk about data. Besides the look and feel of an app and how the “lists” and “views” are wired together with “actions”, the real difference is the data being listed or viewed. And every applications has a specific schema (definition) of data that it is collecting, validating, storing, processing, and retrieving. Once that data schema is defined and the views, lists and actions are specified, the software could almost write itself. And it should! This is the 21st century.
Greg Laird