Software professional with 25+ years in SaaS product development, coding, consulting, platform transformations, and data migrations.

Contact: hikingdave @ gmail.com

What is deconstruction and why does it matter to software developers?

Deconstruction is an approach to a body of work, typically in the areas of literature and philosophy, that looks deeply at the work, seeking to break it down into it component parts. The goal is to seek and find the meaning of each part on its own and as it relates to the whole, in particular noting inconsistencies. This brings an understanding of the work and any inherent conflict between its parts. 

There is a practical result that comes from such an approach, in that once you deeply understand a work, you know both its flaws and is strengths. Although academics and I likely part ways at this point, this is the critical juncture for software development - having understood the work in front of you, it is now possible to improve it.You can resolve some flaws. You can embrace strengths. You can understand the interplay between the technical needs of your software and the business goals of you larger organization, and know what options are available for moving forward.

I am a coder. A decent one. Not an amazing one. But I am a highly productive coder because this process of deconstruction and reconstruction is exactly what I do. I will look at any software upon which I am working, and understand what it parts are, what they do, and why they do it. Then I also contrast that knowledge with the purpose the software is trying to accomplish, and I ask whether or not those parts are the best way to reach our goals. I can merge components that fulfill similar purposes, and split components that are trying to do too much. I can devise new ways to more efficiently reach our goals, refactoring software in ways that make it simpler, more elegant, easier to use, and easier to maintain.

You could ask, "Don't all software developers do this?". And many do - but not all. Some get lost in the weeds of the code itself, and aren't skilled at stepping back out to look at the overall flow of a system. Some people have a hard time throwing out core components. Those components are instead seen as axioms of the systems... unquestionable pieces of the greater work.  

Beginning coders have a different problem - they often will see a complex task in front of them, and not know how to begin breaking it down into smaller pieces that can be coded. Or the opposite problem, of understanding the basics of coding, but without the skills and confidence to build them together into a solution that is greater than the sum of its parts.

My goal, over time, is to write up ways to approaches these types of problems - the problems for beginning coders are easier to approach, so I'll likely focus on those. I hope over time to offer insights of use to experienced developers as well. I'm hoping to add more flavor to learning how to code, so instead of teaching you how to use specific tools, help you discover for yourself how to truly create new works.