Don’t Be Like Hudson

lazyWhen I was a kid in the 60s, we lived in the town of Coshocton, Ohio for a couple of years. Coshocton is in the southeastern part of Ohio near the Pennsylvania border–“Amish Country” as it were.
As you’d expect, there was a group of boys that my brother and I ran with. The Gergley brothers next door. Pete and Gordy across the street. And then there was Hudson. Pretty sure that was his last name, but to our little gang, he only had one name. Hudson.
Hudson seemed, in retrospect, to be the most well off kid on our street. He had a much older brother in college, so he was like an only-child. The rest of us had bigger families. Hudson had all the toys. While each of us had a few Matchbox cars, one GI Joe (with none of the cool accessories like the 50-cal machine gun), and maybe a plastic squirt gun that we could use to play “army”; Hudson on the other hand, had tons of Lego, what seemed like a hundred Matchbox cars, every GI Joe accessory made, and enough really cool toy guns to outfit Seal Team 6.  We liked Hudson. We needed Hudson.
Here’s the problem… Hudson was lazy. The 6 of us would stand at his screen door and beg him to come out and play. He’d rather watch TV (and who knows what was on during the daytime in the 60s) or listen to his brother’s Bill Cosby comedy album. Some days he’d come out and play. But eventually something would go wrong and he’d take all his toys and go home (I’m convinced that’s where that saying originated. Right there in Coshocton in 1965). That would end whatever we’d been doing and we’re back to building a fort or a boat (yes we tried that, I’ll share that story sometime) or riding bikes six miles to see the “waterfall” (a 6-inch drop in the creek off of the concrete running under a bridge–woo hoo!).
Lazy and selfish. And really, isn’t being lazy just a form a selfishness. That’s what we didn’t like about Hudson. Now to be fair, we were probably as interested in Hudson’s “stuff” as we were in Hudson, maybe more. But the 6 of us did everything together. From sledding on the hills at the golf course when it snowed to picking up pop bottles on the state highway so we could cash them in and go downtown to catch a Saturday morning movie. But it was almost always without Hudson who sat home alone with his stuff. I believe we would have all been happy if Hudson had joined us more often.
I hope things changed for Hudson. I hope he found better friends than us. I hope he learned that having stuff wasn’t more important the having friends (or a way to get friends).
Anyway… don’t be like Hudson.
Greg Laird

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

Why Our IT Department Started Using Slack

Slack has become a very popular platform for internal business communications. For those that aren’t familiar, Slack is a messaging platform with some extended features that make it very useful for teams. My favorite feature is the concept of “channels” where you can combine messages related to a particular topic.

So back to why we decided to use Slack. Quick answer, system outages. When systems are unavailable for any reason, we end up texting, emailing, and calling. As the response grows, we typically need to add people to the effort. So now there are multiple threads on multiple platforms that they need to catch up on. Slack solves that.

Now they can jump on our #system_outage channel, and the entire effort from every member of the team is right there. It also becomes a historical record of who did what and when to resolve the issue. This can be searched later if we have similar problems.

What’s next? We look to expand the use of Slack to cover all sorts of team communication and collaboration. We are looking at a #change_management channel to consolidate communication and track approval of changes to the production environment. We’ve started a #support channel for our helpdesk team to work with the application and infrastructure teams to solve problems. Next we plan to see how it works for projects where, for example, we could hold virtual daily stand-ups.


Greg Laird