Excerpt - Introduction
I.1 Why Logic?
I could start playing the game with you and respond with “Why not logic?”, but it is too soon in this
book to tick you off; there will be time enough for that later. This book cam e about for many reasons.
It is not one I originally intended to write as part of this short series, if ever. Many circumstances
coalesced to allow time enough for it, but there still had to be a need for this book to justify writing it.
The need came from a very odd place (at least for those of you unfamiliar with the ways of IT
professionals): conversations in bars.
Oh, this wasn’t conversations with a bunch of grizzled coworkers swilling suds and having a gripe
session. These were conversations with college students when I actually ran into one who was
enrolled in some aspect of IT. My current consulting contract has me staying near a college town, so
when you head out for a beverage or eight, you inevitably run into college students even in the old
fogey bars. What was appalling wasn’t the fact that in a bar with more than 300 people you only ran
into, at most, one IT student, but what they were being taught. Logic isn’t required any more at a lot of
campuses. Many others don’t even offer it as a class.
In today’s pointy-clicky world, logic has been tossed aside. The trouble with tossing aside logic is
that you toss aside what is the fundamental core of application and system design. Once you
understand that logic is no longer being taught, it is easy to understand the complete lack of design
so visible in today’s PC and Unix products. Those students who graduate today and actually accept
a job working with a 3GL writing non-GUI back end applications flounder miserably. W ere there any
justice in the world, they would be able to get their money back from the university which gave them
the degree.
When I obtained my first degree some two decades ago, I saw the beginning of the end for logic in
college courses. They started teaching Pascal in the logic class. The excuse was that students
needed to implement the logic tools they were being taught. The second excuse was that they
needed to know Pascal to survive the data structures class later in the curriculum . Neither argument
was worthy of pushing any language into the logic course. Being in the absolute last group of
students to take the logic class in its pure form, I’m in a unique position to criticize the following
classes. It also helps to have gone back a decade later and heard much the same criticism from
former instructors. They claimed that none of the newer students did very well later in the curriculum.
That a lot of students changed their major when they started hitting the more coding intense classes.
The reason those students floundered isn’t because IT got harder. Indeed, IT had gotten easier by
then with good 3GL compilers and syntax checkers. It was because they had burned almost their
entire logic class learning a 3GL (Pascal) rather than learning the depths of logic. They were
focusing on the syntax of a language. The larger portions of logic, those portions that take you above
simple program design into complex application design and simple systems design, were never
covered. When they got to the more advanced programming classes, they had no frame of reference.
They did not know how to design a control break report, or even what a control break report was. The
last part is really sad considering how most college students have a credit card. Every month they
get a statement for their credit card account that is a control break report.
Why logic? Because you cannot hope to succeed or even survive in software development without it.
Why logic? Because most of you have went through or are going through a college curriculum that
didn’t teach you logic. Why logic? Because the drive to be the absolute best in software development
cannot be taught, but logic can, and you cannot be the best without logic.
In years gone by, hiring a new programmer to your staff was much like buying a new car. You got to
pick and choose the features, but you never had to ask if the car came with an engine. Programmers
from the old curriculums all had been taught logic, you didn’t have to ask. In today’s market, you have
to ask if the car comes with an engine.
I.2 What is Logic?
That is the fundamental question. There are many answers. Depending on the situation
surrounding the question, some answers are more correct than others. When you complete this
book and begin working in the real world of IT, you will constantly use a variant of this question with
every program and system you design. “What is logical?”
No, I’m not trying to lay a bunch of academic babble on you. People don’t buy a book they aren’t
forced to read because they like having academic babble shoved down their throats. I have found few
things more boring than listening to what career academics have said or reading what they have
written. There are several periodicals that handle that market. There was a time in my career when I
believed I could obtain something useful from them, so I paid expensive fees to read those
magazines. What I obtained from them was a substitute for Nytol most of the time.
Logic is the fundamental tool of IT. It is the tool from which all other tools are created. There are
many kinds of logic in the world of IT. Scholars would like you to believe that there is only one
definition of logic and it always yields the same outcome. That statement is incorrect. They will try to
proof their statements with truth tables and lectures that glaze over your eyes inside of 15 minutes.
Had there been even the most remote grain of truth to those proofs AI (Artificial Intelligence) would
have been more than a mid-80s flash in the pan.
For logic to provide the same answer twice, given the same set of truths, you must start in the
same place each time. Logic isn’t a set of gears producing the same output every time you turn a
crank handle. A single instance of a logic path will provide that type of output. In the world of IT, we
tend to refer to that single instance as a program. When a program doesn’t provide a consistent set
of output, we say it has bugs. The term bugs became shorthand for implementation failure. Every
program fails at some point. Because we don’t like to say we exist to create failure, we say we exist
to create software and some of that software has bugs. It is probably a good thing we call them bugs
so the tool to remove them can be called a debugger, otherwise we would be talking about running
our programs through “failure removal” instead of running them through the debugger.
Back in the beginning days of computers, they were a collection of tubes and programmed by
either wiring or tossing a series of switches. There was only one type of logic: hardware. For most
computers it was the “hard-wired” truth. A switch was either on or off. Some computers, though few
exist today, used “frequency logic” for lack of a better term. They were analog, not digital. Most of you
reading this should be familiar with the classic sine wave from your math classes: the perfectly
symmetrical S laid on its side and a line drawn exactly through the middle of it. Everything above the
line was positive, or truth, while everything below the line was negative, or false. Analog was much
like real life. It allowed for varying degrees of true and false. Some of you using digital cameras may
have heard a term called “fuzzy logic.” Fuzzy logic tends to get used in a lot of automatic focusing.
(Those of you reading this who are intimately familiar with analog computers and fuzzy logic, please
allow me some literary freedom here. Conceptually, they are similar as a car and truck are similar.
We don’t want to go too far down a bunny hole at this point.)
There are still some analog computers around, thought not many. I don’t remember the exact
problems they were the best at solving, but there is/was a niche of software development which
could use no other form of computer. I have a nagging thought in the back of my mind that stellar drift
calculations were among the applications best served by analog boxes. If any of you reading this are
old enough to have owned the older cell phones, then you have a shining example of analog
technology. When you were in a bad spot you could still make out pieces of what the other person
said even with all of the static. With modern digital cell phones you simply get a dropped call. Analog
keeps going as long as there is any degree of truth; binary stack dumps. Analog knew there was
interference and allowed for it; binary requires perfection.
Logic has taken many turns during the past two decades. The study of AI and the creation of truth
tables lead to the creation of rules-based systems back in the mid-to-late ‘80s. Truck loads of
dollars were poured into companies claiming they would create thinking machines and personal
helpers with all of the intelligence of a hired servant in just a few short years once the tables were
constructed. There was a “market correction” when none of these start-ups bore the tasty fruit
investors were looking to savor. Financially, it was not as horrific as the DOT COM flame out, and it
did not have quite as many criminals with their fingers in the venture capital grab bag. It did have one
very ugly side effect though — logic got a bad wrap. Colleges pretty much stopped teaching it and IT
started a downward spiral.
Logic taken too far gives you problems like the AI investment debacle. What the industry failed to
realize is that logic, like cholesterol, must exist. There is good logic and bad logic just like there is
good and bad cholesterol.
The short answer is that logic is the most fundamental of IT tools. Logic is what allows you to get
from input to output, no matter what. Logic is the framework upon which every computer application
is developed, even the object-oriented applications.
I.3 Prerequisites for This Book
This book only requires that you have some interest in computers and software development. It will
help if you have poked around with some software development tools or attempted some
fundamental programming on your own. By “fundamental” I’m not talking about some GUI
development product where you only clicked and dragged things together. I’m talking about older,
lower level, C or BASIC programs where you printed “HELLO” to the screen and tried to work out how
to print columns of asterisks from 10 down to one so they looked like a crude bar graph. If that last
problem sounds horribly simple, try doing it without having had a logic class. Try doing it in under an
hour. If you feel like adding insult to injury, try printing numbers going down the left side, along with
as solid a bar as you can print and letters going across the bottom with a solid bar above them so it
looks even more like a bar graph.
Don’t worry if all you have is a casual interest in computers or software development. We won’t be
writing any programs, only mapping out their logic, so you do not even need a computer. You might
want to surf the Web or visit an office supply shop and see if you can find a “flowcharting template.”
This is a little green plastic thing with different shaped holes cut in it. You use it and a pencil to draw
a flowchart on paper.
I.4 Approach of This Book
Most books on programming logic tend to be less than 100 pages in length. The reason for that is
they focus on either flowcharting or pseudocoding, then stop. They give you one or two problem s
that could relate to the real world, then leave you to figure out things on your own. If I’m going to slam
those books that hard here, then you can be assured it will not be my approach.
I will cover the boring and dry components of flowcharting and dabble a little with pseudocode.
From there we will move forward to some of the standard programming situations. This will let you
actually “see” logic in action. It will also allow some “images” to sink into your brains. From there we
will move forward into the general approach of application design.
This may be a book whose later chapters you wish to read two or three times,especially if you are
new to IT. Nothing you do in your career will save you m ore time and anguish than allowing the
career advice chapter to fully settle in. Trust m e on this one. My first year in college I had to take a
class on logic. We had two little paperback books. One for flowcharting and one for pseudocoding.
Needless to say we completed those in the first month. The entire rest of the semester was class
participation. Each session would start with a new problem – usually – and the entire class would be
spent with students calling out or suggesting the steps of logic required while the instructor drew
with chalk. Admittedly, he had it rough for the first few days of that, but once the bit was set in our
teeth, all he had to do was draw and try not to inhale too much chalk dust.
I don’t have a classroom setting for you, nor do I wish to create one. I’m sure someone reading this
book will do that in the end. What I do have is nearly two decades of software development
experience to draw on when creating problems for you. There will be no choice but to start you out
with some of the fluffy ones, but I plan to leave you with some really good ones toward the end.
One thing that was always done in the past was to separate analysis and program ming logic
classes. Now that I’m “long in the tooth,” so to speak, I don’t agree with that separation. I won’t go
into all of the high-minded and far-reaching concepts of application and systems analysis. There are
an awful lot of other diagrams and specification refinement methods. If you learned them all, each
project would have you burning a week up front deciding which method was going to work best for
the current project. I will take you through the “common sense” approach, naturally extending
program logic to application logic to systems design logic.
I.5 Who Should Read This Book?
Anyone who has even the slightest interest in software development or needs to manage the
software development process should read this book. If you are contemplating a career in software
development, then this should be one of the first books, if not the first book, you read before going
too far down that career path. Understanding the most fundamental concepts of the software
development process is critical to success in either of those career paths.
I.6 Why is Flowcharting and Pseudocoding Shunned?
I’ll be honest. I haven’t drawn a program flowchart in nearly two decades. The only time I write what
could be called pseudocode for a module is when I have either a really big chunk to chew or I’m
writing a bid for approval. Notice that I specifically stated “program flowchart” and “pseudocode for a
module.” The devil is in the details. When doing application or systems design work, I either draw or
participate in the drawing of flowcharts for each project. Once you get into VLA (Very Large
Application) or system level designs, you have absolutely no choice. The human mind was not
meant to remain stretched around designs of that magnitude for prolonged periods of time.
Normally, projects of that size take six months to a year before they even get close to a testing stage.
You need really good diagrams to remember what it was you intended to do six months ago so you
can set up useful test conditions.
As you progress in the field if IT, you will begin to understand why companies will spend in excess
of $10,000 for an ink jet or plotter that uses rolled paper three to four feet wide. One system I helped
develop in the past few years had a system flow diagram done from a very high level so
management could understand it. It took two sheets of that paper six feet in length taped on the long
edge to contain the diagram. When it was scaled down to print on regular letter size paper on a
normal ink jet it took close to a dozen sheets of paper taped edge to edge, and that was using fonts
no larger than six points inside of the symbols. You couldn’t read it if it was more than a foot from
your eyes.
Program flowcharting has been shunned because it is a lot of work. A flowchart is only good before
you write your first line of code. Once you start testing, you realize there are problems with your
design and start making changes to the program. The flowchart never gets updated. Bad
documentation is worse than no documentation at all because it leads people in the wrong direction.
In the early ’80s many shops still endeavored to keep their flowcharts current. Once management
got involved and started chanting “cut costs,” flowcharts were the first thing to go.
Pseudocode was simpler. You could write it with any text editor or word processor. In many ways it
was much like COBOL. Some shops used to write pseudocode with such detail that you could
almost put a period at the end of each statement and get it to compile. This level of pseudocode was
impossible to maintain and also died after hearing the “cut costs” mantra. High-level pseudocode
still gets written in quite a few shops. It usually gets wrapped in a word processing template that
calls it a program specification.
In days of old, a new programmer would be given a program specification from a systems analyst,
or just an analyst. That specification would range in quality from incredibly detailed specifications you
could begin coding from, or just a few lines scribbled on a napkin with a sweat ring from a beverage
on it. Laugh all you want at that statement. The most complex systems you will ever get involved with
start out as just a few lines on a napkin. They generally take about five years to settle into a company
and become stable. The reason you end up working on them is they look so simple and innocent
being only a few lines on a napkin.
Once a programmer received a specification for a new program, they would sit down with pencil
and paper drawing out a very detailed flowchart. This flowchart would document close to every line in
the initial version of the program. They would not be allowed to start coding until the analyst reviewed
the flowchart completely and agreed it was correct. When the analyst was too busy to bother with you,
they would reject the flowchart outright with the phrase “Needs more detail.” This statement was
designed to tick you off for a day or two until the analyst had time for you. It really didn’t have much to
do with what you had done. How do I know this? I was once one of those flowchart drawing
programmers who got a flowchart rejected with that exact phrase. A week later I submitted that exact
same flowchart and it was accepted. During that week I did flowcharts for the other analysts
because they had time to chat with me.
Developers who paid their dues got to be programmer analysts. These were the cherished job
titles. Once you became a program mer analyst you never had to draw another program flowchart.
You got to code straight from the specification. W hen the specification was only a few lines on a
napkin you got to work with an analyst to flesh out the specification. Developers weren’t allowed to
reject a specification from an analyst with the phrase “Needs more detail.”
The result was that everyone wanted to be a programmer analyst. Everyone wanted to just “throw
code at a problem and see what sticks.” That was the fun job in IT. Some geeks prided themselves
on how close to the metal they could code. Even if the shop had chosen BASIC or COBOL, they
would find a way to toss in some Assembler code just to prove how much of a geek they were. The
fact that the Assembler code could never port to a new machine, even in the same family of
computers, never stopped the geek of geeks from throwing it into the application.
During your stint as a programmer analyst, you would get to cut your teeth writing program
specifications. Because you weren’t a systems analyst, your specification could never be three lines
on a napkin. Normally you would be the one receiving three lines on a napkin and be told to flesh it
out. Then your specification would have to be reviewed by an analyst or systems analyst before it
would be assigned to a programmer.
Life would then take an ugly turn for you. After one to five years as a programmer analyst you would
be promoted to analyst. It was the only way to get further pay increases. You would also be relieved
of writing any more code. Instead, your life would be application specifications and programmer
management. While you would toggle between writing systems specifications and application
specifications, you would never really do system s design. The task of system s design fell to the
systems analyst. When it cam e to bidding on contracts or very large applications, they would have to
draw a system flow diagram showing how all of the pieces were to fit together. Filling in the actual
details would fall to those below. The only code you would ever get to write was the occasional
operating system command script.
Most programmers went into IT not only for the money, but because they really liked the idea of
coding up solutions to problems. Once they got to the skill level of program mer analyst, most would
change jobs. Indeed, the average length of stay when I was at that level was two years. Developers
who loved to program simply didn’t want to give it up. The only way to avoid it was to leave the
company.
Never let it be said that marketing won’t sell you a product that will kill you. Along came case tools
followed by pick and drag code generators. They would market these products claiming great leaps
in productivity. The tools would have an interface so appealing that even an MBA could generate the
sample contact manager program in under half an hour. That poisoned apple sure tasted sweet to
upper management. They threw tractor trailers full of money at the vendors of those products. Once
PCs with graphical desktops came out, an even bigger slew of “visual” type tools flooded the market.
Every one of them promised to make programmers more productive. Every one of them cost the
industry more than will ever truly be known.
The argument was made on college campuses that students would never have to flowchart in real
life, so why make them do it now? Grading those flowcharts certainly took a lot of time. Drawing
flowcharts was a lot of work. It was agreed that flowcharts would be dropped. Because
pseudocoding was taught in the same class as flowcharting, it died a death by association.
Perhaps the saddest part of this story is that nobody with any clout stood up and answered the
question “Why make them do it now?” Had anyone answered that question, it wouldn’t have been
dropped. Specification writing would have been added to each and every language/tool class added
to the curriculum and IT would have remained a shining star instead of a downwardly spiraling
industry.
Flowcharting is shunned because it is a lot of work. College students want to do nothing but party
when they first get away from home. Nobody wanted to spend their evenings with a table full of
eraser crumbs, which is pretty much what a class requiring flowcharting made of their evenings.
Flowcharting is shunned because management didn’t want to eat the cost of training a developer
who was only going to spend two years at their company. They expected colleges to do that. When
colleges failed, they threw money at tools to eliminate the need, or so they thought.
Flowcharting is shunned because this is a Visa/MasterCard society. Buy now, rack up enough debt
to declare bankruptcy, and avoid paying altogether.
Pseudocoding at the program level died with flowcharting. It survives in a watered down form at the
much higher level of program specification. Until you see actual application pseudocode, you won’t
understand just how watered down it is.
Nobody wants to pay their dues. That first year of flowcharting is horrible. If you don’t drink, you will
find yourself starting. The first few months are bad because you aren’t any good at logic then. You
understand some of it, but don’t really know how to put it all together. By the end of the first year, you
were approaching the level of quality the IT industry needed: The kind of individual who could hear a
problem and begin the design in their head. Not an entire application or system problem , but a
single module or program problem. You would find yourself looking forward to hearing newer
developers ask, “How am I supposed to do this?” Turning around with a smile you would say “It is
accomplished this way” and give a detailed verbal explanation. You looked forward to that day
because that was the day all would know you had paid your dues in full.
Flowcharting is shunned because nobody wants to pay their dues.
I.7 Flowcharting and the Current State of IT
Admittedly, this section probably belongs in one of my “Ruminations” chapters, but it fits here.
There are few uglier tasks in the world of IT than being asked to draw a flowchart. While it may take
you months to track down a bug in a particularly nasty piece of code, there is an immense sense of
accomplishment that follows fixing it and pointing the fix out to all of those programmers who shied
away from the task. When you are asked to draw a flowchart for a large program , it can feel like
being asked to lug rocks from one pile to a new pile ten feet away, then lug them back again.
Flowcharting is a mental training tool that must be endured. There is no other tool that will condition
your mind to be ready for a life in IT. Flowcharting is not a useful learning tool unless you have a
seasoned developer who will take the time to actually review your flowchart and critique it. I can give
you the fundamental examples. There was a method to the madness in the job title hierarchy.
Every year for the past two decades, fewer and fewer students have been asked to endure it. The
result has been that fewer and fewer competent developers have entered the IT job market. We are
not talking about the total body count here, just the percentage of that body count that actually has
employable skills. Most of those developers went straight into coding at shops without any mentor.
During the ga-ga days of massive IT growth, shops that were either low paying or just true Hell holes
to work at had turn over rates that exceeded 100%. Some shops today are Hell holes which find
them selves in the same situation. While the developers who never learned logic or flowcharting
became better at the syntax of the language, they found themselves failing miserably once they were
promoted higher in the company.
Systems analysts have been moved into infrastructure roles and analysts are now doing everything
the systems analysts used to do as far as software design. I am of course talking about shops that
still have analysts. Most have made that a task of the IT department manager.
The reality is that most of the IT professionals who actually took a logic class that required
flowcharting and pseudocoding are approaching retirement. They are as high in the IT shops as they
can get. The staff under them, while technically competent and knowledgeable about the business,
hasn’t focused on logic. They have focused on enhancements and the occasional new program for
the past 10 years. While they know the existing system very well, they have never really been taught
how to design or build one from scratch.
We, as an industry, are already seeing the fallout from this. Skilled coders are being forced into
management roles where every new functionality request becomes an enhancement to the existing
system rather than a new system design. Systems, which were originally designed to do only a few
things really well, have now evolved into a monster performing 20 to 30 completely unrelated tasks.
Some companies have already imploded because they were unable to respond to new information
requests.
You, as a reader of this book and a student, are in a unique position. It is quite possible that you will
go straight from graduation to junior analyst role, completely skipping the coding portion of this
industry. Companies are playing a game of grab right now searching for the cheapest indentured
servants they can buy for the coding portion of projects. Most of those projects end in utter failure that
must then be hidden, both publicly and in the books. What is missing from their mix is logic. The
coders they are hiring for $10/day haven’t been skilled in logic. The highly skilled programmers they
are tossing out didn’t have it in school either, but they have had at least a decade of experience so
they don’t make large blunders at the program logic level. They do, however, stumble at the
application and system design level.
In days gone by, what saved the system analyst when they wrote a three line specification on a
napkin was the quality of people under them . Everyone was trained in logic. Everyone knew what
had to be done to make it work. The project succeeded. What happens now is upper management
issues a one line spec on the back of a napkin. The analyst issues a 12 or fewer page design
document that was always good enough before. The coders who haven’t got a clue about logic hack
something together and deliver it. Then everybody stands around pointing fingers while eyeing the
black smoking hole in the ground where the project was supposed to land.
I.8 Additional Reading
If you like the style and readability of this book you may like to read two additional books written by
myself. They should be appearing or have appeared in the marketplace by the time this book is
published. You need to read these two books in order as they build upon each other. “The Minimum
You Need to Know to Be an OpenVMS Application Developer” ISBN 0-9770866-0-7. “The Minimum
You Need to Know About Java on OpenVMS Volume 1" ISBN 0-9770866-1-5. Being the author, my
opinion of them is somewhat skewed.
I could start playing the game with you and respond with “Why not logic?”, but it is too soon in this
book to tick you off; there will be time enough for that later. This book cam e about for many reasons.
It is not one I originally intended to write as part of this short series, if ever. Many circumstances
coalesced to allow time enough for it, but there still had to be a need for this book to justify writing it.
The need came from a very odd place (at least for those of you unfamiliar with the ways of IT
professionals): conversations in bars.
Oh, this wasn’t conversations with a bunch of grizzled coworkers swilling suds and having a gripe
session. These were conversations with college students when I actually ran into one who was
enrolled in some aspect of IT. My current consulting contract has me staying near a college town, so
when you head out for a beverage or eight, you inevitably run into college students even in the old
fogey bars. What was appalling wasn’t the fact that in a bar with more than 300 people you only ran
into, at most, one IT student, but what they were being taught. Logic isn’t required any more at a lot of
campuses. Many others don’t even offer it as a class.
In today’s pointy-clicky world, logic has been tossed aside. The trouble with tossing aside logic is
that you toss aside what is the fundamental core of application and system design. Once you
understand that logic is no longer being taught, it is easy to understand the complete lack of design
so visible in today’s PC and Unix products. Those students who graduate today and actually accept
a job working with a 3GL writing non-GUI back end applications flounder miserably. W ere there any
justice in the world, they would be able to get their money back from the university which gave them
the degree.
When I obtained my first degree some two decades ago, I saw the beginning of the end for logic in
college courses. They started teaching Pascal in the logic class. The excuse was that students
needed to implement the logic tools they were being taught. The second excuse was that they
needed to know Pascal to survive the data structures class later in the curriculum . Neither argument
was worthy of pushing any language into the logic course. Being in the absolute last group of
students to take the logic class in its pure form, I’m in a unique position to criticize the following
classes. It also helps to have gone back a decade later and heard much the same criticism from
former instructors. They claimed that none of the newer students did very well later in the curriculum.
That a lot of students changed their major when they started hitting the more coding intense classes.
The reason those students floundered isn’t because IT got harder. Indeed, IT had gotten easier by
then with good 3GL compilers and syntax checkers. It was because they had burned almost their
entire logic class learning a 3GL (Pascal) rather than learning the depths of logic. They were
focusing on the syntax of a language. The larger portions of logic, those portions that take you above
simple program design into complex application design and simple systems design, were never
covered. When they got to the more advanced programming classes, they had no frame of reference.
They did not know how to design a control break report, or even what a control break report was. The
last part is really sad considering how most college students have a credit card. Every month they
get a statement for their credit card account that is a control break report.
Why logic? Because you cannot hope to succeed or even survive in software development without it.
Why logic? Because most of you have went through or are going through a college curriculum that
didn’t teach you logic. Why logic? Because the drive to be the absolute best in software development
cannot be taught, but logic can, and you cannot be the best without logic.
In years gone by, hiring a new programmer to your staff was much like buying a new car. You got to
pick and choose the features, but you never had to ask if the car came with an engine. Programmers
from the old curriculums all had been taught logic, you didn’t have to ask. In today’s market, you have
to ask if the car comes with an engine.
I.2 What is Logic?
That is the fundamental question. There are many answers. Depending on the situation
surrounding the question, some answers are more correct than others. When you complete this
book and begin working in the real world of IT, you will constantly use a variant of this question with
every program and system you design. “What is logical?”
No, I’m not trying to lay a bunch of academic babble on you. People don’t buy a book they aren’t
forced to read because they like having academic babble shoved down their throats. I have found few
things more boring than listening to what career academics have said or reading what they have
written. There are several periodicals that handle that market. There was a time in my career when I
believed I could obtain something useful from them, so I paid expensive fees to read those
magazines. What I obtained from them was a substitute for Nytol most of the time.
Logic is the fundamental tool of IT. It is the tool from which all other tools are created. There are
many kinds of logic in the world of IT. Scholars would like you to believe that there is only one
definition of logic and it always yields the same outcome. That statement is incorrect. They will try to
proof their statements with truth tables and lectures that glaze over your eyes inside of 15 minutes.
Had there been even the most remote grain of truth to those proofs AI (Artificial Intelligence) would
have been more than a mid-80s flash in the pan.
For logic to provide the same answer twice, given the same set of truths, you must start in the
same place each time. Logic isn’t a set of gears producing the same output every time you turn a
crank handle. A single instance of a logic path will provide that type of output. In the world of IT, we
tend to refer to that single instance as a program. When a program doesn’t provide a consistent set
of output, we say it has bugs. The term bugs became shorthand for implementation failure. Every
program fails at some point. Because we don’t like to say we exist to create failure, we say we exist
to create software and some of that software has bugs. It is probably a good thing we call them bugs
so the tool to remove them can be called a debugger, otherwise we would be talking about running
our programs through “failure removal” instead of running them through the debugger.
Back in the beginning days of computers, they were a collection of tubes and programmed by
either wiring or tossing a series of switches. There was only one type of logic: hardware. For most
computers it was the “hard-wired” truth. A switch was either on or off. Some computers, though few
exist today, used “frequency logic” for lack of a better term. They were analog, not digital. Most of you
reading this should be familiar with the classic sine wave from your math classes: the perfectly
symmetrical S laid on its side and a line drawn exactly through the middle of it. Everything above the
line was positive, or truth, while everything below the line was negative, or false. Analog was much
like real life. It allowed for varying degrees of true and false. Some of you using digital cameras may
have heard a term called “fuzzy logic.” Fuzzy logic tends to get used in a lot of automatic focusing.
(Those of you reading this who are intimately familiar with analog computers and fuzzy logic, please
allow me some literary freedom here. Conceptually, they are similar as a car and truck are similar.
We don’t want to go too far down a bunny hole at this point.)
There are still some analog computers around, thought not many. I don’t remember the exact
problems they were the best at solving, but there is/was a niche of software development which
could use no other form of computer. I have a nagging thought in the back of my mind that stellar drift
calculations were among the applications best served by analog boxes. If any of you reading this are
old enough to have owned the older cell phones, then you have a shining example of analog
technology. When you were in a bad spot you could still make out pieces of what the other person
said even with all of the static. With modern digital cell phones you simply get a dropped call. Analog
keeps going as long as there is any degree of truth; binary stack dumps. Analog knew there was
interference and allowed for it; binary requires perfection.
Logic has taken many turns during the past two decades. The study of AI and the creation of truth
tables lead to the creation of rules-based systems back in the mid-to-late ‘80s. Truck loads of
dollars were poured into companies claiming they would create thinking machines and personal
helpers with all of the intelligence of a hired servant in just a few short years once the tables were
constructed. There was a “market correction” when none of these start-ups bore the tasty fruit
investors were looking to savor. Financially, it was not as horrific as the DOT COM flame out, and it
did not have quite as many criminals with their fingers in the venture capital grab bag. It did have one
very ugly side effect though — logic got a bad wrap. Colleges pretty much stopped teaching it and IT
started a downward spiral.
Logic taken too far gives you problems like the AI investment debacle. What the industry failed to
realize is that logic, like cholesterol, must exist. There is good logic and bad logic just like there is
good and bad cholesterol.
The short answer is that logic is the most fundamental of IT tools. Logic is what allows you to get
from input to output, no matter what. Logic is the framework upon which every computer application
is developed, even the object-oriented applications.
I.3 Prerequisites for This Book
This book only requires that you have some interest in computers and software development. It will
help if you have poked around with some software development tools or attempted some
fundamental programming on your own. By “fundamental” I’m not talking about some GUI
development product where you only clicked and dragged things together. I’m talking about older,
lower level, C or BASIC programs where you printed “HELLO” to the screen and tried to work out how
to print columns of asterisks from 10 down to one so they looked like a crude bar graph. If that last
problem sounds horribly simple, try doing it without having had a logic class. Try doing it in under an
hour. If you feel like adding insult to injury, try printing numbers going down the left side, along with
as solid a bar as you can print and letters going across the bottom with a solid bar above them so it
looks even more like a bar graph.
Don’t worry if all you have is a casual interest in computers or software development. We won’t be
writing any programs, only mapping out their logic, so you do not even need a computer. You might
want to surf the Web or visit an office supply shop and see if you can find a “flowcharting template.”
This is a little green plastic thing with different shaped holes cut in it. You use it and a pencil to draw
a flowchart on paper.
I.4 Approach of This Book
Most books on programming logic tend to be less than 100 pages in length. The reason for that is
they focus on either flowcharting or pseudocoding, then stop. They give you one or two problem s
that could relate to the real world, then leave you to figure out things on your own. If I’m going to slam
those books that hard here, then you can be assured it will not be my approach.
I will cover the boring and dry components of flowcharting and dabble a little with pseudocode.
From there we will move forward to some of the standard programming situations. This will let you
actually “see” logic in action. It will also allow some “images” to sink into your brains. From there we
will move forward into the general approach of application design.
This may be a book whose later chapters you wish to read two or three times,especially if you are
new to IT. Nothing you do in your career will save you m ore time and anguish than allowing the
career advice chapter to fully settle in. Trust m e on this one. My first year in college I had to take a
class on logic. We had two little paperback books. One for flowcharting and one for pseudocoding.
Needless to say we completed those in the first month. The entire rest of the semester was class
participation. Each session would start with a new problem – usually – and the entire class would be
spent with students calling out or suggesting the steps of logic required while the instructor drew
with chalk. Admittedly, he had it rough for the first few days of that, but once the bit was set in our
teeth, all he had to do was draw and try not to inhale too much chalk dust.
I don’t have a classroom setting for you, nor do I wish to create one. I’m sure someone reading this
book will do that in the end. What I do have is nearly two decades of software development
experience to draw on when creating problems for you. There will be no choice but to start you out
with some of the fluffy ones, but I plan to leave you with some really good ones toward the end.
One thing that was always done in the past was to separate analysis and program ming logic
classes. Now that I’m “long in the tooth,” so to speak, I don’t agree with that separation. I won’t go
into all of the high-minded and far-reaching concepts of application and systems analysis. There are
an awful lot of other diagrams and specification refinement methods. If you learned them all, each
project would have you burning a week up front deciding which method was going to work best for
the current project. I will take you through the “common sense” approach, naturally extending
program logic to application logic to systems design logic.
I.5 Who Should Read This Book?
Anyone who has even the slightest interest in software development or needs to manage the
software development process should read this book. If you are contemplating a career in software
development, then this should be one of the first books, if not the first book, you read before going
too far down that career path. Understanding the most fundamental concepts of the software
development process is critical to success in either of those career paths.
I.6 Why is Flowcharting and Pseudocoding Shunned?
I’ll be honest. I haven’t drawn a program flowchart in nearly two decades. The only time I write what
could be called pseudocode for a module is when I have either a really big chunk to chew or I’m
writing a bid for approval. Notice that I specifically stated “program flowchart” and “pseudocode for a
module.” The devil is in the details. When doing application or systems design work, I either draw or
participate in the drawing of flowcharts for each project. Once you get into VLA (Very Large
Application) or system level designs, you have absolutely no choice. The human mind was not
meant to remain stretched around designs of that magnitude for prolonged periods of time.
Normally, projects of that size take six months to a year before they even get close to a testing stage.
You need really good diagrams to remember what it was you intended to do six months ago so you
can set up useful test conditions.
As you progress in the field if IT, you will begin to understand why companies will spend in excess
of $10,000 for an ink jet or plotter that uses rolled paper three to four feet wide. One system I helped
develop in the past few years had a system flow diagram done from a very high level so
management could understand it. It took two sheets of that paper six feet in length taped on the long
edge to contain the diagram. When it was scaled down to print on regular letter size paper on a
normal ink jet it took close to a dozen sheets of paper taped edge to edge, and that was using fonts
no larger than six points inside of the symbols. You couldn’t read it if it was more than a foot from
your eyes.
Program flowcharting has been shunned because it is a lot of work. A flowchart is only good before
you write your first line of code. Once you start testing, you realize there are problems with your
design and start making changes to the program. The flowchart never gets updated. Bad
documentation is worse than no documentation at all because it leads people in the wrong direction.
In the early ’80s many shops still endeavored to keep their flowcharts current. Once management
got involved and started chanting “cut costs,” flowcharts were the first thing to go.
Pseudocode was simpler. You could write it with any text editor or word processor. In many ways it
was much like COBOL. Some shops used to write pseudocode with such detail that you could
almost put a period at the end of each statement and get it to compile. This level of pseudocode was
impossible to maintain and also died after hearing the “cut costs” mantra. High-level pseudocode
still gets written in quite a few shops. It usually gets wrapped in a word processing template that
calls it a program specification.
In days of old, a new programmer would be given a program specification from a systems analyst,
or just an analyst. That specification would range in quality from incredibly detailed specifications you
could begin coding from, or just a few lines scribbled on a napkin with a sweat ring from a beverage
on it. Laugh all you want at that statement. The most complex systems you will ever get involved with
start out as just a few lines on a napkin. They generally take about five years to settle into a company
and become stable. The reason you end up working on them is they look so simple and innocent
being only a few lines on a napkin.
Once a programmer received a specification for a new program, they would sit down with pencil
and paper drawing out a very detailed flowchart. This flowchart would document close to every line in
the initial version of the program. They would not be allowed to start coding until the analyst reviewed
the flowchart completely and agreed it was correct. When the analyst was too busy to bother with you,
they would reject the flowchart outright with the phrase “Needs more detail.” This statement was
designed to tick you off for a day or two until the analyst had time for you. It really didn’t have much to
do with what you had done. How do I know this? I was once one of those flowchart drawing
programmers who got a flowchart rejected with that exact phrase. A week later I submitted that exact
same flowchart and it was accepted. During that week I did flowcharts for the other analysts
because they had time to chat with me.
Developers who paid their dues got to be programmer analysts. These were the cherished job
titles. Once you became a program mer analyst you never had to draw another program flowchart.
You got to code straight from the specification. W hen the specification was only a few lines on a
napkin you got to work with an analyst to flesh out the specification. Developers weren’t allowed to
reject a specification from an analyst with the phrase “Needs more detail.”
The result was that everyone wanted to be a programmer analyst. Everyone wanted to just “throw
code at a problem and see what sticks.” That was the fun job in IT. Some geeks prided themselves
on how close to the metal they could code. Even if the shop had chosen BASIC or COBOL, they
would find a way to toss in some Assembler code just to prove how much of a geek they were. The
fact that the Assembler code could never port to a new machine, even in the same family of
computers, never stopped the geek of geeks from throwing it into the application.
During your stint as a programmer analyst, you would get to cut your teeth writing program
specifications. Because you weren’t a systems analyst, your specification could never be three lines
on a napkin. Normally you would be the one receiving three lines on a napkin and be told to flesh it
out. Then your specification would have to be reviewed by an analyst or systems analyst before it
would be assigned to a programmer.
Life would then take an ugly turn for you. After one to five years as a programmer analyst you would
be promoted to analyst. It was the only way to get further pay increases. You would also be relieved
of writing any more code. Instead, your life would be application specifications and programmer
management. While you would toggle between writing systems specifications and application
specifications, you would never really do system s design. The task of system s design fell to the
systems analyst. When it cam e to bidding on contracts or very large applications, they would have to
draw a system flow diagram showing how all of the pieces were to fit together. Filling in the actual
details would fall to those below. The only code you would ever get to write was the occasional
operating system command script.
Most programmers went into IT not only for the money, but because they really liked the idea of
coding up solutions to problems. Once they got to the skill level of program mer analyst, most would
change jobs. Indeed, the average length of stay when I was at that level was two years. Developers
who loved to program simply didn’t want to give it up. The only way to avoid it was to leave the
company.
Never let it be said that marketing won’t sell you a product that will kill you. Along came case tools
followed by pick and drag code generators. They would market these products claiming great leaps
in productivity. The tools would have an interface so appealing that even an MBA could generate the
sample contact manager program in under half an hour. That poisoned apple sure tasted sweet to
upper management. They threw tractor trailers full of money at the vendors of those products. Once
PCs with graphical desktops came out, an even bigger slew of “visual” type tools flooded the market.
Every one of them promised to make programmers more productive. Every one of them cost the
industry more than will ever truly be known.
The argument was made on college campuses that students would never have to flowchart in real
life, so why make them do it now? Grading those flowcharts certainly took a lot of time. Drawing
flowcharts was a lot of work. It was agreed that flowcharts would be dropped. Because
pseudocoding was taught in the same class as flowcharting, it died a death by association.
Perhaps the saddest part of this story is that nobody with any clout stood up and answered the
question “Why make them do it now?” Had anyone answered that question, it wouldn’t have been
dropped. Specification writing would have been added to each and every language/tool class added
to the curriculum and IT would have remained a shining star instead of a downwardly spiraling
industry.
Flowcharting is shunned because it is a lot of work. College students want to do nothing but party
when they first get away from home. Nobody wanted to spend their evenings with a table full of
eraser crumbs, which is pretty much what a class requiring flowcharting made of their evenings.
Flowcharting is shunned because management didn’t want to eat the cost of training a developer
who was only going to spend two years at their company. They expected colleges to do that. When
colleges failed, they threw money at tools to eliminate the need, or so they thought.
Flowcharting is shunned because this is a Visa/MasterCard society. Buy now, rack up enough debt
to declare bankruptcy, and avoid paying altogether.
Pseudocoding at the program level died with flowcharting. It survives in a watered down form at the
much higher level of program specification. Until you see actual application pseudocode, you won’t
understand just how watered down it is.
Nobody wants to pay their dues. That first year of flowcharting is horrible. If you don’t drink, you will
find yourself starting. The first few months are bad because you aren’t any good at logic then. You
understand some of it, but don’t really know how to put it all together. By the end of the first year, you
were approaching the level of quality the IT industry needed: The kind of individual who could hear a
problem and begin the design in their head. Not an entire application or system problem , but a
single module or program problem. You would find yourself looking forward to hearing newer
developers ask, “How am I supposed to do this?” Turning around with a smile you would say “It is
accomplished this way” and give a detailed verbal explanation. You looked forward to that day
because that was the day all would know you had paid your dues in full.
Flowcharting is shunned because nobody wants to pay their dues.
I.7 Flowcharting and the Current State of IT
Admittedly, this section probably belongs in one of my “Ruminations” chapters, but it fits here.
There are few uglier tasks in the world of IT than being asked to draw a flowchart. While it may take
you months to track down a bug in a particularly nasty piece of code, there is an immense sense of
accomplishment that follows fixing it and pointing the fix out to all of those programmers who shied
away from the task. When you are asked to draw a flowchart for a large program , it can feel like
being asked to lug rocks from one pile to a new pile ten feet away, then lug them back again.
Flowcharting is a mental training tool that must be endured. There is no other tool that will condition
your mind to be ready for a life in IT. Flowcharting is not a useful learning tool unless you have a
seasoned developer who will take the time to actually review your flowchart and critique it. I can give
you the fundamental examples. There was a method to the madness in the job title hierarchy.
Every year for the past two decades, fewer and fewer students have been asked to endure it. The
result has been that fewer and fewer competent developers have entered the IT job market. We are
not talking about the total body count here, just the percentage of that body count that actually has
employable skills. Most of those developers went straight into coding at shops without any mentor.
During the ga-ga days of massive IT growth, shops that were either low paying or just true Hell holes
to work at had turn over rates that exceeded 100%. Some shops today are Hell holes which find
them selves in the same situation. While the developers who never learned logic or flowcharting
became better at the syntax of the language, they found themselves failing miserably once they were
promoted higher in the company.
Systems analysts have been moved into infrastructure roles and analysts are now doing everything
the systems analysts used to do as far as software design. I am of course talking about shops that
still have analysts. Most have made that a task of the IT department manager.
The reality is that most of the IT professionals who actually took a logic class that required
flowcharting and pseudocoding are approaching retirement. They are as high in the IT shops as they
can get. The staff under them, while technically competent and knowledgeable about the business,
hasn’t focused on logic. They have focused on enhancements and the occasional new program for
the past 10 years. While they know the existing system very well, they have never really been taught
how to design or build one from scratch.
We, as an industry, are already seeing the fallout from this. Skilled coders are being forced into
management roles where every new functionality request becomes an enhancement to the existing
system rather than a new system design. Systems, which were originally designed to do only a few
things really well, have now evolved into a monster performing 20 to 30 completely unrelated tasks.
Some companies have already imploded because they were unable to respond to new information
requests.
You, as a reader of this book and a student, are in a unique position. It is quite possible that you will
go straight from graduation to junior analyst role, completely skipping the coding portion of this
industry. Companies are playing a game of grab right now searching for the cheapest indentured
servants they can buy for the coding portion of projects. Most of those projects end in utter failure that
must then be hidden, both publicly and in the books. What is missing from their mix is logic. The
coders they are hiring for $10/day haven’t been skilled in logic. The highly skilled programmers they
are tossing out didn’t have it in school either, but they have had at least a decade of experience so
they don’t make large blunders at the program logic level. They do, however, stumble at the
application and system design level.
In days gone by, what saved the system analyst when they wrote a three line specification on a
napkin was the quality of people under them . Everyone was trained in logic. Everyone knew what
had to be done to make it work. The project succeeded. What happens now is upper management
issues a one line spec on the back of a napkin. The analyst issues a 12 or fewer page design
document that was always good enough before. The coders who haven’t got a clue about logic hack
something together and deliver it. Then everybody stands around pointing fingers while eyeing the
black smoking hole in the ground where the project was supposed to land.
I.8 Additional Reading
If you like the style and readability of this book you may like to read two additional books written by
myself. They should be appearing or have appeared in the marketplace by the time this book is
published. You need to read these two books in order as they build upon each other. “The Minimum
You Need to Know to Be an OpenVMS Application Developer” ISBN 0-9770866-0-7. “The Minimum
You Need to Know About Java on OpenVMS Volume 1" ISBN 0-9770866-1-5. Being the author, my
opinion of them is somewhat skewed.
| Copyright © 2007 TheMinimumYouNeedtoKnow.com. The information on this page may not be reproduced or republished without prior permission from Roland Hughes. |
| HOME :: ROLAND HUGHES :: BOOKS in the SERIES :: ORDER :: SITE MAP |
About Logic to Work in IT
| About the Book || Reviews || Table of Contents || Excerpt |
