Coding it "old school"

For instance, "no one can ever tell you what a UML diagram means."

If you're old like I am, this is so true. Maybe it's true for everyone.

This article is about how some of the old-timers at Microsoft still program with their good ole text editor. I am not the Luddite that some may be, but my take on MDD (model-driven development) is that it might be good in the initial stages of layout and design, but at some point you're gonna have to lay some lines of code. And it can't do shit for that problem.

A buddy was kvetching today at lunch about how his new architect wants him to crank out a bunch of UML (unified modeling language) diagrams of the application he's been working on. He said the guy was "old school" but I don't think we did UML diagrams back when I started writing code (i.e., back in the real old school). Shit, we didn't even know anything about OOAD (object-oriented analysis and design) back then. I think it was just being invented, or something. (So, by the way, was UNIX. Sorta.)

I am not against more advanced methods of programming, but as Don Box said when they asked: "But when there are 500 things, [graphical programming] is completely unusable. You zoom in and zoom out and you lose all context. I think it's just smokin' dope." It's also difficult to fully fathom something when it's some hundred-friggin-thousand lines of code, but if the code is done well, you can look at individual methods (about 10 to 50 lines) to fathom them, then upward through the stack until you reach the top. So, it's not all bad.

I wish my friend good luck with all those UML diagrams. I told him he should get the damn architect to do them. That should keep the guy busy for at least 6 months, or more. Just about right, IMO.