and yet this is exactly the prevailing situation today. We are inundated with tools which are light years more advanced than stacks of Hollerith cards and traditional engineering forms with flowcharts on them. Yes, I'm crusty I guess. I started in the very early '80s and I had sort of a unique situation: I stole my education on a VAX 780 at the University of Washington. I started off on video terminals (Z-29s) and never punched cards except for laughs. Line numbers were important when you dropped a stack of cards; they didn't mean much when you could see the source in "screen mode", as opposed to "line mode", on a real live 24x80 character cell screen.. what a concept. Before that I worked as an electronics tech; so I'm familiar with flowcharts, schematics, all that ilk as well.
I saw a paper tape machine once upon a time, too. It was at Lakeside School. It was Billy and Paul's toy, I guess; didn't sound like they were inclined to share, and I didn't end up going to Lakeside.
Automated code management systems aren't just for huge systems any more. Every integrated development environment corrals you into a "project", and that's just the way it is. Support for versioning varies. Why is that? Is that because the customers don't see a point to it or because the coders didn't see the point? I guess you have to be a coder to understand the need for nightly backups. No, in fact that's true. But it's the accountant who'll insist that the backups be taken offsite, and rightly so.
Nobody does makefiles by hand unless they're truly obsessed with portability... or makefiles. And interestingly a lot of people are obsessed with makefiles as an art form. They demonstrate in some obscure manner that your code can sail the seas of architecture, from the lands of big-endian to little-endian, and still compile.. even if it can't necessarily do something useful at every port of call. Good makefiles say "I am an artist. I have sailed beyond the horizon and returned. Here, eat some scrotty salted fish and let me show you how to tie a boline."
Compiles are cheap enough that we can use them to catch syntax errors, and are likely to remain so until they figure out how to get per-use charging figured out again. This is more profound than it sounds. When I started playing with that VAX 780, I didn't pay for what was in actuality some pretty expensive processor time. My level of effort to edit and resubmit was cheap on a video terminal as opposed to punch cards. When I got my first commercial gig and was in the big compile phase they just about sh1t Skittles when they got the bill from the timesharing service; they were punch card people, and it simply never occurred to them that somebody might work this way. Nowadays processors are cheap. It's too easy to change code, really. Oftentimes people make changes to purturb the system. This wouldn't be bad if they actually had a plan and knew^H^H^H^Hstrike that had the discipline to evaluate the effects of those purturbations.. actually construct a failure matrix, something like that.
Microsoft has successfully marketed the term "object-oriented" and VisualBASIC (but do you remember Hypercard?) puts the code where the action is. I am convinced that a lot of the acceptance of what is accepted as "object-oriented design" is a direct result of the Microsoft marketing machine. Hypercard for the Macintosh predates VisualBASIC by several years and has an elegant and dynamic scoping mechanism that looks first for a procedure or variable in the actual interface object, then in the window, then the static class that the window was instantiated from and finally from the entire application.. And XCMDs are still cleaner than .DLLs. And furthermore the entire MacOS is object-oriented with respect to such code fragments, first looking for them in dynamically loaded resource forks, then in the application's resource fork, and finally in the System. Prior to Microsoft's marketing of VisualBASIC I remember distinct edicts not to use field triggers for edit checks in things like VAX FMS because "it makes it hard to find the code". Whatever. Go on, ask me about "relational databases". I dare ya! Why do we have relational databases that require a reorganization when fields are added or deleted?
There are wonderful tools out there which will take a high-level design and decompose it into procedures, data dictionaries... objects... wait: procedures and data structures are objects aren't they? Of course they are. Modules are objects, clearly. What's going on here, why is there such a snit, really, about Java and C++: surely it's not because anybody thinks that the Microsoft Foundation Classes (MFC) are anything but utter crap?! It's because they elide the distinction between data references and procedure invocations. This is a good thing. Really.
But I can walk into the majority of shops, take people into separate rooms, ask them about how they go about getting things done (about their process) and I won't get the same answers!
The tools are great, even though they totter oftentimes at the brink where complexity falls into the abyss of chaos: your results will not be less buggy than the tools you use. Maybe this is why last time I checked, which was about a year ago, if you wanted to build a device driver for Windows NT 4.0 on i86 you had to do it from the DOS shell to be supported as a developer. But the tools don't address the issue of people interacting in the process of getting things done. You think I'm kidding, right? Why, it says it does that right here on the box...
This is sad, really. Why don't programmers think it's funny? Why doesn't anyone else understand it?
If you haven't seen, if you don't know, if it isn't blatantly clear to you that far too many changes to software are prosecuted for the simple capricious desire to change process, or to ram a process down people's throats when they can't be made to accept it willingly, then you haven't really been in this business long enough to be a professional, have you? I think the wrong people end up in charge of I.S. at most organizations. The job of I.S. in any successful organization is going to be mainly stewardship of the processes and practices embodied in the software infrastructure. I think the accountants should be in charge; not because they enjoy sniffing people's butts and auditing each other (do they really enjoy that?) but because they understand stewardship and oftentimes it seems that noone else in the organization does. The wrong people are drawn to leadership positions in I.S.: the kind of people whose real thrill in life is no more and no less than making things change. The power to change process, the instant gratification, is psychologically addictive to these folks: other than the physical plant nothing has the power to turn an organization upside down like I.S.; and nobody would actually consider (would they?) shutting off the heat when people don't meet quotas or upping line voltage "to get more done".
Same thing applies to the tools: as without, so within. I wasn't kidding at all about the "..says so right here on the box.." comment.
The key practices of this profession remain the same even after all of these years:
sadly these tenets remain as elusive as they ever did. It seems I can never mention these key practices without begging the question of who says that these are key practices anyway? The SEI's Capability Maturity Model, for one. I don't think software is exempt from engineering practices; I don't care what model you use, but there must be an acknowledgement that there are such things as "sound engineering practices" that span technical disciplines.
Is there any question about writing two digit years instead of four digits? There shouldn't be: my checks come preprinted this way, or did until this year. I expect that when I order new checks in the year 2000, they'll come preprinted with the "20____" again. This is because it's convenient. Meanwhile if I write "'99" or "'00", I don't think anybody's going to be confused. Anybody who keeps writing "2000", "2001" after next year is going to be as weird as the Technocrats. They were a pre-WWII political movement who felt that society should be entrusted to the engineers. There was a guy named Tom Lehrer in the late '50s and early '60s who wrote a bunch of weird songs such as Poisoning Pigeons in the Park (self-explanatory), I Hold Your Hand In Mine (..dear, I really don't know why, because every time I kiss it, I get bloodstains on my tie..), Who's Next? (..I'll try to stay serene and calm, when Alabama gets the Bonb), and most importantly for my purposes here an Ode To Werner Von Braun (..'vonce ze rockets go upp who cares verr zey come down, zat's not my department', says Werner Von Braun).Was there ever any question about exactly when it would become a problem? It's a constant and on-going problem for well-engineered systems. Even entering two digits, most of the time you want your users restricted to a much narrower range. For instance if you're talking about school kids then +/- 40 years ought to do it; anything outside that range is a typo and edit checks should catch it and inform the user. Even with poorly engineered systems or when the occasional mistake occurs, problems have occurred. DECWindows crashed the world over a few years ago when the code, which was ported from Unix, exceeded the well-documented 10,000 delta date restriction on VMS. DEC came out with a patch in advance of the event but that didn't stop a lot of people from having to install it after the fact from the operator's console. Long before Melissa, Sun unix boxes were shut down all over the internet when a worm took advantage of another problem for which a patch was available and widely publicized. Many unix clocks will run out in another 30 years or so. While there are enough poorly designed and negligently maintained systems out there that some disruptions are inevitable around the year 2000-2001, for my money the long-term disposal of nuclear and highly toxic waste remains the real risk to life as we know it. Exactly who is responsible for initiating an analysis of the impacts of the problem? Now this is a specious question. The fact that the Y2K situation has captured the public eye is a manifestation of the belated recognition by management that information systems are here to stay. The direction that the debate and discussion has taken is confirmation that while recognition has now occurred, most management is clueless in regards to what to do about it: with how to actually manage information systems. Regardless of whether or not they test and fix their systems to dodge this particular bullet, the information systems infrastructure will continue to get ever more complex.
I've come to the conclusion that there are a couple of key points when it comes to explaining things to "the customer", and that explaining it to the customer is all that matters:
I don't give a rat's, dog's or dil's ass whether or not the problem is fixed unless I understand what it was. You can fix code all day long, but without rational risk assessment you're still at risk; and without an understanding of your systems and their interactions with all of the other systems, you can't do a rational risk assessment. In a word: DDT.
I have to be able to train the users up quickly because they're busy, they have other things to do: if they didn't, they wouldn't be users now would they? They're also going to forget, because they're going to go away and work on other things. I've never had trouble explaining data flow diagrams to biologists or to electrical engineers. That's because they generally have transferable domain knowledge. In the former case that is a metabolic pathways chart or diagram of dependent chemical reactions; in the latter it is the electronic schematic diagram. There are differences, of course, but the similarities are more sublime. If I was working somewhere and they had a tool for symbolically documenting metabolic pathways or preparing schematic diagrams and the users were familiar with the tool, I'd propose using that tool for the high-level documentation. In fact, I have proposed this; nobody's ever taken me up on it.
The essence needs to be conveyed in a single diagram so that everybody remembers that we're talking about the entirety of a system, so that they can see the impacts of their piece on the whole. A single picture is also a lot easier to keep track of than a whole bunch of different views of a system; that's just human nature. This doesn't mean I don't decompose into subdiagrams: a machine is composed of other machines. But it does mean I put a lot more effort and stock into what's conveyed by the diagram than I do to the data dictionary or procedure specifications: if the diagram doesn't convey enough, then I change the diagram, or how the diagramming is done. My problem with Booch is that is that they've got even more ancillary documents than you get with the traditional DFD. Good thing they've got a computer tool to manage all that complexity! How long is it going to take the users to learn all of those tools, and what is their knowledge retention going to be like? Oh, and did I mention all of those per-seat licensing fees?
I'd like to be a team player and say "oh yeah, Booch is the way to go" but I've seldom had the opportunity to write code with programmers, for programmers. The Booch people tend to complain that data flow diagrams don't capture enough information about "objects". But for the most part, we're dealing with an assembly line mentality out there and there are two kinds of objects: equipment, which is usually stationary, and parts, which flow through the process. It is not my job to "redefine" someone's manufacturing process in order to write a system for them. To do that is just the tail wagging the dog, turning around and doing to the management of the organization what management does to information systems. We know how to capture information (all kinds of information) about the equipment used in a manufacturing operation and about the parts used in making products. I continue to use a modified data flow diagram paradigm for most of my high level designs. So the nodes and what flows are objects: big deal. Actually it is a big deal: the users can generally understand it. When I build in "remote monitoring" of my "shop floor equipment", they understand that too. For that matter what I see paradoxically is that code that is written "...with programmers (or at least engineers), for programmers (or at least engineers)" doesn't have a Booch anywhere near it! sendmail, popper, swish, apache, linux: a body of free work of incomparable value. Most of it is written in straight C, not even C++. But that shouldn't matter, you should still be able to do a high-level design using Booch methodology. But why bother? So presumably the community that works with Booch is cranking out some amazing high-level designs that will result in a comparable body of useful works. Where is it? In the RFCs? The just-approved Internet Printing Protocol looks like it has some opportunities for rational application of object-oriented design: what are you waiting for, folks? Java?
Usually because it's not their job to write code. Funny thing, but most of them look at "software engineers" and don't see a whole lot of engineering going on. As a result of this, we don't get a lot of respect. Am I overstating the case? Maybe, maybe not. I guess I would argue that they are emulating what they see as "best practices" in the majority of cases, and that the first place to look if you don't like that idea is in a mirror.
If you want to be treated like an engineer, then act like an engineer. The other part of this is that if you do this in a shop where there are engineers in other disciplines, you're inviting criticism of your professional practices: again, there are some tenets which span disciplines. Otherwise, why would you presume to criticize their code? Because it's code? Because you're going to be stuck with maintaining it? Well I got news for ya buddy old pal, they have to build the hardware to support your screwed up software, too. Every piece of shop floor equipment built with an idiot light is an argument against the notion that software is being engineered. If you're engineering a system, it's not hardware against software or machines against I.S.
Maybe somebody should inform management about this radical idea!
Like you didn't know already: money. We want to get paid; we need to earn a living like everybody else.
They want it cheap, they want it yesterday, and they want it to work, right? Pick two out of three. Like everybody else, short term personal goals such as greed and survival get in the way of longer-term organizational goals. That's why we do it, why we put up with the status quo.
It's too late to do anything about it once you relocate, take the job, or pay the money to the vendor. Which brings me to my final point:
Answer: as many times as I can. It's how I qualify prospects and decide whether or not I want to get involved wtih them at all: What do you measure? How do you measure? How do you get things done? Tell me about your software development process? Do we interact with other engineering disciplines? How are we managed? In as many ways as I can. This is how I advertise as well as promulgate professional conduct. Considering that at the present time more than half of the shops out there have no real process then mathematically it stands to reason that I'll have to burn through twice as many prospects as someone who doesn't qualify like this.
The shops with no process aren't deterred by any of this in my experience. Just mystified.
The 5 stages of Dilbert in a corporate setting:
Think about it, though: it works for me, it might work for you, too. If your organization hasn't progressed beyond Dilbert Stage 2 and you think you can use someone like me, by all means give me a call or drop me a note.
"A company's personnel is its heart, although traditional accounting methodologies have consistently denied the workforce an assessable value."
-- Martin Yate, Hiring the Best, A Manager's Guide to Effective Interviewing
(c) Copyright 1999 by Fred Morris, Seattle WA USA. The public display of this document at the author's web site only grants you the right to view it; you may not cache it, print it, or reproduce it electronically without the permission of the author in writing.
Fred Morris Consulting, Licensed in Seattle, WA, USA. 1984-2009. Presently in the process of moving to Tacoma.
Document/Collaboration/Content Management Tools and Solutions
An Internet Plumber... not a web cowboy
telephone: 253.538.5091
e-mail: x0xconsultingx0xatx0xm3047.net