Take A Hint: Software Architecture and Human-Centered Design

There's always something new to learn. Hopefully, there's a subsequent spark that ignites when you integrate new knowledge and come out the other side with an enhanced set of neural connections. The best ones, I've found, come from taking concepts from a neighbouring disciplines (or better yet, disciplines that are completely alien to each other), and applying them in a way that suddenly explains a concept or idea that was...let's say cloudy.

There's a great talk by Adrian Kosmaczewski which he aptly titled Being A Developer After 40. Now, I'm not 40, but his advice holds true for any age - which is essentially the conclusion of his talk - age doesn't matter. In my roundabout way I'm coming to the point of this article, I promise.

While reading Don Norman's The Design of Everyday Things (one of the many books Kosmaczewki recommends for expanded learning), I came across his 7 stages of action diagram, and how it relates to Human-Centered Design. Briefly, the stages are: Goal, Plan, Specify, Perform, Perceive, Interpret, and Compare.

This hit me like a ton of bricks, not because it was something alien to me, but because this summed up exactly how I wanted a code base to be designed. Why should HCD be relegated to just tangible products? In a digital age, the intangibles need love too.

In the diagram above, we would replace the goal, with the desired functionality. The world is the API, UI, or really anything you are interfacing with. Good software architecture should attempt to address both the bridge of execution and evaluation, but not only in terms of the user and the application but between the programmer and the code base. Let's take a practical example of hitting an API endpoint.

1. Goal: Hit the endpoint and retrieve data
2. Specify: Give all relevant information to your class that is going to perform the call
3. Perform: Fire the request
4. Perceive: Evaluate if anything has happened at all
5. Interpret: Parse out the results for evaluation
6. Compare: Check if the result is what you were expecting

Steps 1 - 4 are well covered in most courses on developing software; it's steps 5 and 6 that are often left out, or badly implemented. You shouldn't have to crawl through a stack trace or step through hundreds (if not thousands) of lines of code with breakpoints to find the source of a bug - there should be a clear channel of communication from the code base BACK to the programmer. This might seem ridiculous because the programmer wrote the code, why would he/she need it to explain itself back to him. BECAUSE IT'S BETTER THAT WAY.

Techniques like Test Driven Development, Unit Testing, Integrated Testing, etc all do this fairly well, but even these tools are often left out in favour or faster development. I would go even further; I dream of a code base that spits out a human-readable snapshot of where something is wrong, what the problem may be, and possible ways to fix it. At this point in time we don't have IDE's that are that smart, but we should start thinking about how to add some of our own smarts into our projects. Write helper functions for debugging, use unit tests, check your assertions, anything but leaving out interpretation and comparison.

Software IS a product, which means it has many of the same design needs as a physical product. The user should not be the only one kept in mind when designing delightful usability. Extend this thinking to yourself (or think of other developers who will be working with your code) and see where it takes you.

If you need a place to start, always go to the grammar. Take a page out of the Swift API Guidelines and strive to write grammatically correct code and make use of explicit commenting. The focus should be on designing code base AS interactions between the programmers and the project. This will have big payoffs down the road in less on-boarding hassle, clearer interfaces, and a joyful coding experience.

"Always end with a quote" - thanks American History X - so here's a good one; architect software code to be less"exasperatingly difficult to use, the tools of a cult of professional engineers and designers who seemed to take a perverse pride in making them as obscure and intimidating as the oracles of ancient Greece" (from Dealers of Lighting).

*This first appeared on MOBILE CYBERPUNKS. You can find the original article here.

__________________________

Harrison Ferrone is an experience-driven software engineer, game developer, creative technologist, and Certified ScrumMaster working out of Munich, Germany. His first LinkedIn Learning course was published in 2016, with more going live in the coming months. He mainly focuses on Swift, C#, and Unity, but recently began branching out into C++ and Unreal Engine 4. When he's not coding or reading everything he can get his hands on, he's chasing the feel of golden era hip-hop and taking afternoon naps with his girlfriend and their three cats.