That's Not The Way I'd Do It
“That’s not the way I’d do it.”
He went on to tell me how he’d do it. After thinking about it a couple of days I realized that the way he’d do it, while not wrong, wasn’t any better than what was originally there. In grousing about it, the chairman of the Computer Science Department remarked,
Yeah, that’s just like a programmer.
While that made me feel better, it was also aggravating. Out of sheer habit, what compels programmers to be so petty? I don’t mind a little one-upmanship, but some discussions need to be about finding a better solution and not forever trying to tell someone how smart you are. (By the way, this isn’t the first time I’ve mentioned this problem in a post, but I’d like this to be an invitational rant and get some reader comments.)
I’ve worked with people in a lot of different fields, and while some pettiness can be found in just about all professions, We’re Number One! when it comes to the That’s not the way I’d do it (TNTWIDI—pronounced tin-widi with a short “i”) syndrome.
Those of us who live in Glass Houses….
For someone who writes a blog about how to program better using OOP and Design Patterns, I’m on pretty thin ice when it comes to grumbling about telling people how to program. Furthermore, most of the comments we get are extremely helpful—let’s face it, we’ve got a pretty smart readership. (That’s due to the topic—not necessarily Chandima and me!) However, at the same time, we get snippish little missives now and again that reflect TNTWIDI, and because we take all comments seriously (unless they’re trying to peddle something), we find it a little aggravating to waste time on what amounts to a bad habit among programmers.
At the same time that we get TNTWIDI, the great majority of comments we get are excellent. For example, in a series of recent interchanges with Timo concerning the Flyweight pattern, we more or less concluded that Timo may have stumbled upon a new design pattern. Likewise, Alan had pointed out a mess I made of certain agile concepts and resulted in my changing a post. Chandima’s posts on Pure MVC has led to a huge number of great comments and given us direction for post content. So, while TNTWIDI is a problem, let’s remember that most of the comments we get are great.
Helpful Comments: Bomb Defusing 101
Imagine you’re working with a number of people to solve problems in defusing bombs. Some of the people have a lot of experience defusing bombs and have studied the chemistry and engineering of bomb-making extensively. Others less so, and still others have no experience and have read little about the topic. Now everybody in the group wants to diffuse bombs successfully. If someone makes a TNTWIDI comment, however, they have to use their method to defuse the bomb.
Such a system would do two things: The TNTWIDI’s would get blown up in short order, and the rest of us would think carefully before we shot off our mouths just to show the group how smart we were. However, there’s a danger in such a practice—it would silence the less experienced. For example, a novice member of the group may ask, “What about a mercury fuse?” Suppose, no one in the bomb defusing group had considered that and a mercury fuse was exactly what a particular bomb used. They’d get blown up because they limited discussion.
Let’s All Get Better
Not too long ago I read an article in which an MIT professor of computer programming/engineering remarked that a certain process that saved a few cycles in the time it took to execute a program was a waste of time. The reason was that it took a huge number of man-hours of programming to save a few milliseconds. In other words the savings would be so small that no one using the program would notice. However, it might take an extra week or month to create such a program. In short, the argument was that many are still acting like we’re using 8-bit processors and 48k of RAM when we’re working with 64-bit processors and RAM measured in gigabytes.
Those particular remarks resonated with me because design patterns focus on human development as much as they do on computer processing. In fact, other than the Flyweight, I cannot think of a single design pattern that speeds up processing. What many fail to understand about design patterns, and why I believe they are so difficult, is that the focus is on relationships between classes. That is the reason that the symbols in the class diagrams are all about describing relationships. If you compare a flowchart with a class diagram, instead of flow control, you see a description of class relationships—or put otherwise—the relationship between participants (those classes, interfaces and subclasses that make up the pattern.)
If our discussions can better focus on relationships, and if we think of relationships when attempting to understand a particular design pattern, we’ll be on the right track. This does not mean that we should not discuss coding. Far from it. Rather, when discussing coding we need to focus on how the code sets up or expresses a given relationship. We need to ask,
Does this code best reflect a given relationship?
You may well ask, How do we determine whether the code reflects the relationship? If that question came to mind; then you’re on the right track.
Let’s hear from you
What are your thoughts about moving ahead in 2010 and beyond with design pattern. Let’s hear from you! Don’t worry, there’s no possible TNTWIDI for this kind of post!
The “That’s Not the Way I’d Do It”: Justifiable Homicide in 32 States by William B. Sanders, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.
Bill Sanders
That’s not the way I would have talked about it!
(sorry)
“what compels programmers to be so petty?”
That’s easy: insecurity. And it’s not just programmers. I’m reminded of an old joke from my music days:
Q: How many guitarists does it take to change a light bulb?
A: Ten. One to change it, and nine to stand around with their arms folded saying, “Yeah that was okay, but I could have done it better.”
Welcome to 100,000 years of evolution.
Hi Useless,
I think I’m having one of those days….or to quote Homer Simpson,
Cheers,
Bill
Hi Wendy,
Thank god for musicians…we are not alone.
Cheers,
Bill
what’s worse is how often I find myself forced to refactor/rewrite/clean-up The TNTWIDI’s mess once they code us into a corner again.
Actually, that might just be me, but most of the time, I find it incredibly useful when someone tells me how he would have done a certain thing, even though his method might not be better than mine (or might even be worst).
Obviously, without explanation, TNTWIDI is pretty useless. But if it comes with an explanation of an alternate way, even if it’s not a better way, I tend to alway find it enlightening.
And for about the same reasons, when I look at someone else’s code, I tend to go on and on with “Hey, why did you do that that way ?”, it’s not meant to say that I find that his way suck, only that I’m willing to find out what its pros (and cons) are compared to the way I’d have done it. Just my 2 cents.
Hi Danny,
That’s right! It can waste a huge amount of time and you have to undo it all and go back to your original starting point.
Kindest regards,
Bill
Hi Axelle,
I think that all of us would agree with you when it comes to really wanting good ideas and better ways of coding. That was how I got into Design Patterns in the first place. When Jonathan Kaye first introduced me to the concept of a State Machine, I was blown out of my socks and am very grateful to Jonathan for taking the time to explain it to me.
The kind of comment I am talking about is the thoughtless TNTWIDI that is based on “See how smart I am,” rather than, “Let’s look at it this way because it follows Design Pattern Principle A and OOP Principle B.”
I’m with you 100% when it comes to being open to ideas and learning something new about programming virtually all the time. Danny’s point seems to hit the nail on the head when he points out that TNTWIDI comments are more likely to cause other problems because the comments really aren’t about programming—they’re about the programmer’s ego.
Great hearing from you and hope to hear more.
Kindest regards,
Bill
For me, that’s definitely the way I’d do it … if I could. I’m still a novice with both ActionScript and Design Patterns.
As for the original question for 2010 and beyond I am going to continue learning and using Design Patterns for my little educational applications. DPs have a sort of poison that make you want more and more.
And they are fun!
Best wishes
Curro
Hi Curro,
We’re going to be going over all of the basic relationships in design patterns, and that should add to a firm DP foundation.
Kindest regards,
Bill
Some people just don’t make good people. I see life in the same light as Ziegler. There’s a lot of different ways to “skin a cat” and anyone who doesn’t see that is doing their selves a great injustice. But I guess it takes all kinds!
Jonathan,
Lots of ways to skin a cat, and that’s why it’s important to differentiate the TNTWIDI from useful information. I suppose a better way of putting it is:
If we can look for good criteria and communicate those ideas; then we’re dealing with people who are sincerely interested in collectively moving ahead with understanding. However, when someone spouts out a TNTWIDI whenever they look at your code; then it’s not too helpful.
Bill
It’s all about patterns and practice. I think a lot of us
understand the language but not all interpret the same.
Hi Sharetut,
I agree with you. Readers of this blog know the language and algorithms inside-out. It’s always difficult to move from a functional understanding of a computer language to an understanding of OOP principles that are used together in design patterns. If anyone thinks they understand all of this the first time they look at it; they probably don’t.
Thanks for your insights,
Bill
One of the things I have seen for many years are people that code to code so that it looks complicated. This obviously stems from either insecurity or an over inflated ego.
The only real ‘mistake’ being done, especially when dealing with DP is not to consult others before undertaking the development cycle. More is less, think more, code less.
I and many other non elitist programmers have also come to see that most of the time, a pattern, even though well thought of, becomes restrictive and actually hinders the development process, in essence, it all comes down to polymorphism.
Being that programming is still in an infant stage (believe me) we fail to see while we standardize and regiment our methods the errors of other disciplines that have come across similar bottle necks in their evolution. One could look at symbolic logic for example in order to see where thought and practicality are logically demonstrated not to meet in a reasonable manner.
Theory is theory, and practice rarely resembles what the books say.
As for people with no social etiquette, well, thats the world we live in and its not about to change soon. Change yourself and the world will change with you. :)
Hi Since the 80’s,
I agree with you that consulting with others is essential–on several different levels. First and last, you need to consult with your customer at length before setting down to write the code. Then there are other programmers with whom you are working. You have to craft a plan to work together and optimize any areas of expertise (e.g., the guy’s who’s good at SQL, the gal who’s a great UI developer) and organize around a plan. Finally, if you’re working in a big shop, coordinate with administration so that your resources don’t dry up before the project is done—or you don’t hog resources that are not used.
So on the issue of communication, we’re in total agreement. The other issue is (as you so well put it) a matter of social etiquette. If you see something in another’s program that you believe could be improved, you need to be delicate for two reasons. On the one hand, you don’t want to sound like a jerk. That can be handled by the way you put it to the programmer. On the other hand, you may not understand the program and your suggestions are flat out wrong. So tread lightly. I can’t tell you how many times I’ve had some well-meaning comment suggest that I could “save” programming code by removing an interface!
As for your comments about “elite” programming, you wouldn’t be looking at this blog if you weren’t interested in elite programming. Let’s face it, there’s no such thing as elite programming; so let’s just drop that term here and now. We can distinguish about four types of programming:
You might say that both agile programming and design patterns are just extensions of OOP, and you’d get no argument from me. Here our focus is on good Design Pattern programming in ActionScript 3.0 using OOP. It is difficult to learn and implement. Does that mean you’re too dumb to learn it? Of course not. It means that while the transition from Sequential to Procedural programming is pretty easy, and from Procedural to OOP is a little more difficult, the transition to Design Patterns is more difficult still.
At this point there are two directions you can take: 1) I’m too busy; 2) I want to climb Mt. Everest. In terms of practicality, Design Patterns were developed for the practical work of getting programs done effectively and efficiently for businesses. An early sponsor was IBM, and they didn’t do it because they’re nice guys. They saw this kind of programming as practical; so I don’t want to hear anything about Design Patterns being impractical. What’s impractical is re-inventing the wheel every time you sit down to program.
I guess the title “Since the ’80’s” indicates you’ve programmed since the 1980’s. That reminds me of a cop who would boast about having “20 years experience” and so he knew how to be a good police officer. One of the higher ranking officers pointed out that,
I know a programmer who was just like that. Instead of improving his programming skills by learning new programming techniques and approaches, he just learned more programming languages. So instead of growing taller, he just got fatter. That programmer was me. Now, I’m glad I learned several different programming languages from machine language to PHP; but I really needed to become a better programmer. I was fortunate to run into the right people at the right time several years ago, and I migrated first to State Machines and then to Design Patterns. I attended several OOPSLA meetings (where design patterns were introduced) and got to know people who were a lot smarter about programming that I. I learned from them. Sure, I was the dumbest guy in the room; but after several years, I’m not any more. Design patterns went from being hard to the only thing that is challenging enough to be interesting.
Cheers,
Bill