Creative Code Refactoring: Design Thinking Applied in Software DevelopmentAakash SudhakarBlockedUnblockFollowFollowingMay 14If you’ve spent any time writing code for an app you’re building, a service you’re prototyping, or simply playing around in your text editor, you’ve probably thought to yourself:I could probably do a better job writing this code.
It’s a thought that occurs often to anyone from amateur coders to seasoned software engineers – applying complex ideas into code requires incredible amounts of intuition and laser-like focus.
It becomes easy to forget the higher-level picture of why we’re writing the code we choose to write, or even the nature of the problem we’re opting to solve.
That’s where the Design Thinking Process comes in.
The Stanford d.
School’s Design Thinking Framework.
(SOURCE: Interaction Design Foundation.
)The Design Thinking Process is a test-motivated ideation and product development framework originating out of Stanford University’s d.
School that comprises of five key steps: Empathy, Definition, Ideation, Prototyping, and Testing.
The process follows a general strategy: connect with a problem deeply to the point of parametrizing and drawing sufficient boundary conditions.
Then, come up with ideas for code implementation and prototype the code snippets using pseudocode & interview techniques.
Finally, create and test code to solve the original problem.
Let’s walk through an example of Design Thinking applied in Code Refactoring with a classic example of algorithm programming:How can we grab the top three most frequently occurring words in a list of words?To demonstrate an example of functioning code with next-to-no thought put into usability and readability, I present to you this beautiful abomination of Python code.
It’s tough (but totally possible) to get more convoluted than this.
Yikes.
????Thankfully, we can use the Design Thinking Methodology to refactor and reform our code to something a lot more readable and usable.
The first step in the Design Thinking Process for refactoring our code is empathizing with our audience.
It’s imperative that we identify factors relating to our audience that relate to our final product.
In the case of a code snippet, the factors generally remain the same: flexibility, readability, and modularity.
Our readers don’t want a complex-as-all-hell one-liner that accomplishes the task but is nearly impossible to maintain or comprehend.
Let’s attempt to build our code to be something that’s flexible, readable, and modular.
Something that’s simple to understand and capable of solving our problem in an efficient manner.
Our second step in the Design Thinking Process for code refactoring is better defining our problem scope.
Now that we understand why we want to solve our problem, we need to identify parameters and potential issues.
Important parameters for us to consider about this code snippet include that we need to input a list of words and return the top three words by frequency.
That is, we want to return to the user the three words that occur most often in our given list of words.
This brings us to our third step in the Design Thinking Process for code refactoring: ideating on potential solutions.
We can certainly use a convoluted approach above where we simply try to brute force as much code into one line as possible.
Unfortunately, as we’ve previously discussed, that may not be very scalable or effective to communicate to others.
We want to avoid confusing, complex, and chaotic code as much as possible.
(SOURCE: Reddit.
)We would prefer using functional code that clearly communicates the intent of each line and effectively connects to the task at hand.
If you can functionalize and augment your code to be more modular and readable, it’s always a win for both you and your audience.
This thought leads us to our fourth step in the Design Thinking Process for code refactoring: prototyping solutions for communicability.
This is what coding interviews and challenge questions are notorious for practicing: one’s ability to communicate a complex idea using basic tools at one’s disposable.
It’s one thing to be able to code a complex algorithm, but can you simulate the understanding of the algorithm with just a marker, a whiteboard, and your mind within a set time limit?While coding interviews are a more isolated case of solution prototyping, it underlies a critical concept in software development: creating an initial version of a technology by which people can understand your intent can help immensely down the road in terms of development and experience.
To give you a clearer picture, here’s a quick pseudocode snippet of the aforementioned word frequencies problem that I drummed up.
Given a list of wordsDefine a function to create a word frequency histogram object Take the word list as an input Loop over each word Add the word as a new histogram element Increment word count depending on relative occurrence Return the frequency histogramDefine a function to sort our word frequencies into a list Take the frequency histogram as an input Convert the histogram into a list of word-frequency pairs Sort the list based on decreasing frequency rates Return the sorted list of word-frequency pairsDefine a function to print top three words by occurrence Take the sorted list of word-frequency pairs as an input Loop over top three word-frequency pairs in list Return the word in each item pairIt may seem redundant at times, but this pseudocoding methodology clearly communicates even the most basic of ideas to anyone from professional software engineers to persons with virtually no coding experience.
And that’s the point.
Finally, we have the fifth and final step of the Design Thinking Process for code refactoring: testing and productionizing our code.
This is often where coders and developers jump to first, without getting an intimate understanding of what it is they’re doing and why they’re choosing the approach they’re choosing to solve their problem.
Now that we’ve battled through each step of the Design Thinking Process, we can simply look back at our pseudocoded structure and – while considering the parameters and boundaries that we’ve drawn in prior steps – convert it into testable and viable code.
It’s how we can turn this:…into this:While it may be more code, it definitely looks better, right?.????The Design Thinking Process is powerful and can help everyone from beginner developers to advanced level engineers.
I highly recommend those of you looking to augment your software experience to use to Design Thinking Process in your work.
It may just transform the way you think about code for years to come.
.. More details