I didn’t really know what to title this post, so I picked something very generic. There might be some truth to it.
I don’t know if anyone else feels or thinks this way, but I think it’s time someone calls the “code design” camp out. What do I mean? Code design is a crock and it pretty much is like the Abominable Snowman. It doesn’t exist. I think we tend to believe it exists in large because we see patterns in code. Now, it might be one of those religious type existences where some people would believe that we would have a lot more bad code if it weren’t for the morals held up by design principles, read religious tenants. Okay, so that might be jumping to conclusions too early. But lets break this down and see where we arrive at.
How Does One Design Code?
I think depending on who you ask, you will get various answers. Often, it’s really difficult to see what’s right and what’s wrong unless it’s just clearly wrong. I think the grand illusion here is that most people really want to believe that you can engineer code like you can something mechanical or electrical. I’m certainly not saying you can’t. However, the one thing that mechanical and electrical engineers don’t have to deal with often is scope creep. You’re going to have to think this one out for yourself. If you apply Internet Literal Quickest Path to Conclusion Logic to what I just said, you’re going to sound really stupid when you start to talk. Obviously, there are degrees of differences. If you have experience with attempting to design code, you’ll know what I mean. If you don’t, then keep trying to design code. My answer to this question is at the bottom.
What About Design Patterns?
You should probably know what they are for job interviews. There’s a weird double standard to this one. If you read the description for the design patterns, you generally think, “Oh wow, that’s what it’s called. I’ve used that so many times in the past!” But if you try to take one of those design patterns and use it in a design…how often does it really work out like you expected? I think they’re effective communication tools. I’ve always found that with a lot of force, you can generally make them fit. You might undo them later though.
…about job interviews…and then code…
So you go to an interview and they ask you all these questions about how you should do this and that? What do these words mean? What scenario would you use this design pattern in? You answer, get the job. You look at the code and what do you see? From my personal experience, I normally see a program that does a specific thing – absolved of any of the weirdo details that I was asked about in an interview. However, I do often hear those words I was asked about in the interview used in conversations about the code. But rarely do they transfer from the conversations directly into design except for variable names.
The Stupid Visio Diagrams
Does anyone really use this? I’ve seen charts at companies made from this stuff. But the few times I did try to follow the charts to see what went where – there were sections that were missing. When I asked about it, I was simply told, “oh, that didn’t really work out in practice.”
If you’re really intelligent and insightful and consider yourself intellectually above your peers, all of what I have said is stupid. Stop reading.
Now, if you have a real interest in figuring out one of the biggest problems that plague us coders, please continue.
I am certainly not advocating we don’t design our program and libraries. I am advocating we remove the ideas and concepts that have been dreamed up in the past two decades that do not work at all in code design.
I find myself designing code by thinking about a component I want to code and figuring out how to fit it into my existing code. To visualize this design, I will write pseudo code( read C++ ) to see if it compiles. Then I have it print function calls to make sure the ordering is correct. I rarely graph anything. I might right out the names of the variables.
I gave up on the code design books a few years ago. Their ideas always felt too restrictive for what I wanted to do. My approach is to see how things play out in practice. Code, to me, embodies a particular frame of thinking that postulates itself around requirements criteria at a certain time. Later on, I’ve often found that what I was thinking when I implemented these criteria isn’t robust enough. This is generally due to a better understanding of the problem and the elimination of requirements that didn’t make sense.
The motivation of this post comes from how Maya plug-ins are written in C++ and the love/hate relationship people have with them. I will expand on this in the next post.
