For what it is worth, I love this article.
Funny that I should look at this thread - Gonzaga University is in Spokane and when I was reading this at my husband’s store today just about a mile from GU, a student from GU came in and bought some books.
It’s all true, and it’s not just big corporations or systems software programming teams. Even hovering on the periphery of a tiny Mac consumer software company, I’ve seen almost everything he describes.
For example, I have three T-shirts, a ceramic coffee mug, a toy telephone, and a big pile of 2-inch binders from various three-day Open Doc seminars put on by Apple over a period of about six months. Open Doc promised wonderful programming power, was still not working by the time of the third seminar, and vanished almost overnight. Fortunately, it was so hard to understand that I never did get around to commiting any company resources to it.
One of the things that was most startling to all of my military and civilian bosses over the years was my refusal to exhibit the “can do” attitude. I always did as I was told, but I always made sure that I told them my version of the truth first. Strangely enough, I never suffered any repercussions. I’m sure that it’s because they always knew in their hearts that I was right. 
What the CEO at Casady & Greene hated the most was my refusal to give him a serious answer about when my current project would be completed. I would always start with “I don’t know.” If he kept pushing, I would eventually say something like “No later than April of 2032.” I’d already forced him to read The Mythical Man Month, so he knew that I was right. I think that’s the book that has a formula for changing a programmer’s prediction to real time. It’s something like:
- Multiply the number by 3 (or 6, or 10).
- Increase the time unit to the next higher.
So, “3 hours” becomes “9 days”, “6 days” becomes “18 weeks”, “5 months” becomes “15 years”, and so on.
Unfortunately, now that I am both CEO and head programmer of my own little non-company, the head programmer often makes predictions to the CEO, who then stupidly passes the predictions along to the customers without applying that formula. Some people never learn. 
Wow. I’ve seen most all of that in my years in programming.
A new trend now which drives me insane is the concept of “reusability”. The idea is that you can write a piece of code, in a separate file that can be resued by other programs. This way common tasks don’t have to be rewritten.
Great idea in theory. The problem is most code isn’t reused. Yet programmers have now decided that having 200 separate files located in ten different places is the “hip” thing to do.
We had an outside consulting firm write a new front end for our document management software. The resulting code was so complex and such a mess that debugging was a nightmare. And, like all complex code, it had bugs. In addition, the code wasn’t documented at the code level so a call to another file woudn’t indicate the actual file containing the called function. The worst part was that only about 10% of that entire mess was ever “reused” by other parts of the application.
The problem boils down to how detailed the progammer wants to get with the concept of reusability. If I want a program to print “Hello World” do I write a single function to print a text string or do I want to be really hip and cool and modern and write eleven different functions, all in separate files to print each individual letter and space? Heck what about a function for every key on a keyboard. You KNOW you’re going to print a lot of “E’s” so why not?
Great article. I’m glad I’m doing support now.