Tell Me I'm Wrong And I Have Nothing To Worry About
I'm looking for meeting room 401-2a. I'm running 15 minutes late for a 30-45 minute meeting. However, I'm on the fourth floor. I see a room that starts with 401 so I head in that direction. Unfortunately that's not the room I'm looking for, but I go in anyway because I recognize a few faces and perhaps I can get directions. But little did I know, I was walking right into a war of finger-pointing-and-I-told-you-so.Before I could make an about face and get clear, one of the familiar faces said, "Hey, I bet Cameron knows. He'll tell you exactly what the problem is." At this point, I'm kinda asking myself how come I didn't get better directions before heading to my meeting. So I turned and said, "I'll be glad to help if I can, what's the deal?" Then for the next 30 minutes or so (forget about my original meeting) I patiently listened to fairly detailed but conflicting accounts of how a particular in-house application processes a set of messy, poorly defined, moving target transactions. And that said application worked just fine until multi-threading was added to several of the application's modules over this past year.
Okay, because I happen to know a couple of the guys and gals in this quagmire and because I now need a legitimate excuse for missing my original meeting, I decided to try to help. So the very first thing I asked for was the most recent system design documentation prior to the threading, and I also wanted the module design documentation that reflected the new multi-threaded modules. It was as if suddenly a ghost appeared behind me. The room fell silent. I looked at a few puzzled faces, then finally someone said, "What do you mean by 'design documentation'? We have the latest version of the source code that we can show you and we kept the version of the source prior to the initial multi-threading code that was added." I dropped my favorite Nasa ink pen (it can write upside down and underwater) to the floor. I subconsciously knew that my mouth had just dropped wide open, so I made an attempt to close it without looking too surprised. And I said, "Well you know any detailed design you might have of the system, ER-diagrams, UML diagrams, block diagrams. Whatever you use to do detail documentation of the design of your systems." There was another awkward 20 seconds of silence, and someone else spoke up and said, "We all know how the system works. We've been working on this system for over 10 years. Everybody has just kinda memorized how its put together and how it flows." So I said, "What you're telling me is that the design is in your heads". "I guess you could say that", one of the younger guys responded. I asked, "So how did you go about adding threads to your application?" And the response was, "Well we looked at the modules that we wanted to work faster and we added the thread code". I stooped and picked up my favorite Nasa pen and told them that I was running late for a meeting, and if they could e-mail me some kind of system design that captured before and after, I would see what I could do.
The name of the organization and individuals in the meeting are purposely kept out of my account, so that I don't loose any friends. But the size and the nature of the organization has me worried. Sure, I know all kinds of application development goes on with little to no real software engineering in place. But I kinda put that application development in the class of 'non-professional' development or folks that for the most part don't know what they're doing. But when I see this at a major institution, I get really worried. Has everyone dispensed with formal methods, true-tried software development methodologies, and software engineering? Has everybody caught the-Website-in-a-box-mobile-phone-app-even-grandma-can-do-it fever? Skipping formal software engineering methodology with even trivial applications can ultimately lead to disaster. Tell me that I'm wrong and that developers are not trying to add multi-threading or parallel programming to their applications without properly paying the software engineering piper? Let us know that your organization uses formal software development methods and sound software engineering practices in the development of all software (especially software that requires parallel programming). Tell us we have nothing to worry about?