So what is good structure in software? What makes one language, design or architecture better than another? These are all very difficult questions to answer. So far, I have not found a litmus test; but I have noticed some features in what I call good code that ultimately lead to good structure.
Having spent most of my life as a software developer, always striving to write better code, I have discovered there are thousands of ways to solve a problem; some better than others each with their own set of advantages and disadvantages. Every developer is constrained by his knowledge, experience and time limitations to prototype new ideas. There is always a region of unknown improvements and great ideas that never get implemented.
Is it easy to spot well-structured code? To this question I have to say yes, good structure in code just stands out. I was teaching a class of electrical engineering students last year when a student turned in some code that read like poetry. It was clear, concise and well organized. The logical thought process of what he was trying to accomplish in code jumped off the screen as if were yelling “YES, it is that simple!”
As I reviewed my student’s code, I realized some people are just gifted, having natural knack for things. For most of us mortals though, it’s a process of continual improvement. We build up a library of knowledge, what works very well and what does not no matter how hard we try. Over time, our value as a programmer is not in what we know works, but in what we know doesn’t! And from our library of knowledge, we formulate patterns that lead to structure and eventually complete architectures.
This brings me back to when I first started writing automation software to control test equipment. I was at White Sands Missile Range all caught up in a debate over what was the best software to use for a specific project. At that time it was a tossup between LabView, Visual Basic and C++. Each of the engineers on the team were giving reasons and examples why the team should choose one language over the other. As I was stating my case, one of the senior developers, who had remained quiet until he chimed in with “Syntax is Symantec, Structure is Everything!” Then he continued with “You can do anything in any language, they key is in how you organize the software.”
Over the years I’ve learned good structure comes from knowing more than one language. Because the syntax and structure of each language is different, sometimes forcing the developer to think about how to accomplish a task outside his box of knowledge.
So what defines good structure? Software shouldn’t be complicated; it should be simple and intuitive. We as software engineers should always think in terms of simplification and understandability. Too many developers have a complicated mind set when the approach a problem. Yes the algorithm may be very complicated, but it should be coded so both the compiler and a person can understand it.
This brings us to the second most important feature of well structured code. It should be readable! Compressing code into fewer and fewer lines of code is only good as long as the code remains readable. Napoleon believed that a good battle plan should be understood by all his commanders down to every corporal. Applying it to software, quality code should be readable by all members of your team.
Another peeve of mine is Spaghetti Code! Code that jumps all over the place is hard to follow; if it’s hard to follow, then I categorize it as unreadable. Jumping around in code and interdependencies between separate modules are the biggest indicators of poorly structured code.
A good structure should incorporate modularity. Breaking the overall project up into manageable pieces that are then assembled into the complete software solution will allow each piece to be updated independently. But the level of modularity has to be contained into logical groups of related objects. Defining the dividing lines in a large software project is a very complex operation and may take several iterations to get it right.
The hardest concept I have to teach my new programmers when they are learning structured programming is delegation. In software I define delegation as the process of pushing responsibility to the lowest level of code. The best example of poor delegation and poor structure is when I see a LabView application that has set the GPIB address on the first page. The problem is the GPIB address now needs to be wired from the top of the application all the way down to the VI’s that communicate with the instruments. It’s not spaghetti code, but on a complicated calibration procedure it can look like a wiring nightmare.
I have started using Legos® as a metaphor for describing software design. There are tens of thousands specialized little Lego® pieces, as well as those core building blocks—just like there are different languages and tools to support each language. So like Legos®, software can also be assembled in an infinite number of ways.
