Critical Thinking in Software Development

Every software developer has been here before: Staring at a mass of code, wondering how in the world it was ever created, why does it exist, and what exactly am I supposed to do now?

Software is always created to serve humans, but it does so in most complicated and messy ways. Problems compound, people come and go, and soon the non-developers on the team are wondering if it will ever be fixed at all, while the developers want to bang their heads against the wall. Though the causes of the issues are as wide as the issues themselves, several common threads exist in the major problems of the world of software development. Near the top of the list is the lack of critical thinking.

Critical thinking in the software world in many ways is the opposite of what many developers think about the work that they do. With the vast range of tools at their disposal, the amount of shared knowledge, and the general culture of the profession, it is very easy to slip into patterns that may not have been thought through very much, if at all. What does that lead to?

Because each situation is unique, no overall answer can be given. For awhile, the solution may work and work very well indeed, until bugs crop up. Or perhaps it has collapsed right out of the gate and the person in charge is unable or unwilling to work on it anymore. How about systems running on obsolete languages that need to be ported over now?  

There are several different ways to approach these situations. The fastest fix will be different than a complete overhaul. Getting systems just back online is different than spending hours chasing down bugs. This is where critical thinking about the situation comes into play.

What facilitates critical thinking in the software world? After all, the people behind the code had thought about it before creating it. Even the most pointless part of the code had a point in someone’s mind before it started a mass of confusion. Can those thought processes be called critical thinking?

It is easy to say no in frustration, and perhaps they did not think when they created it. The truth of the matter is, as a creator of software, you do have a responsibility to think about these kind of situations and how to prevent them. That is the heart of critical thinking in the software world.

The vast majority of the struggle depends on a mindset change from “this is the way I want to do things” to “what is the best way to do things”. Or, to put it another way, create the code as if any and everyone that will have to work on in afterwards knows where you live.

It’s hard and messy. It’s far easier to do what you know, or what is fun and challenging to you, or even what someone else is telling you to do. It’s fun to implement the same processes and write the code that experts in the field recommended. It’s invigorating to change things up and race boldly ahead. But what does that mean for the future?

It means that someone, somewhere down the line will have to fix it. Someone who may not understand how or why it was written in the first place. Someone else’s time will be spent over a problem that had been solved and now is not. And that someone might very well be you all over again!

To continue in the cycle of what we like vs. what is best is a sure way to create more work. In the short run, in the middle, or in the long haul, it will come back again and again. We already see it today in many different areas. As the field of software continues to mature, the mistakes of today are the upheavals of tomorrow.

Start developing your critical thinking skill set today! Talk to other, like-minded professionals in your groups. Think about the need behind the problem before tackling the issue itself. Try to understand the ‘why’ before the ‘what.

And go create. Because that’s why you do this in the first place, isn’t it?