OK, I want to try something different. I want to demonstrate how I was taught to decompose any problem. So to do this, I propose having fun with it, as my instructor did many, many years ago. If you can't decompose your problem, you will never be able to be a programmer/analysis or literally anything else in life. Oh you can code, but is it the most efficient way of doing it? When you need to make changes to it, do you literally have to start over? Now, I truly believe if you give 10 engineers the same problem, lock each one away from the other, you would get 10 different solutions. Which by the way is fine. The more difference of opinion, the better the end produce.
Just always remember that it is your opinion, not fact until you've completed at least, an operational prototype and gauged it against your design and the customer's required needs. If someone attacks your methods, be sure to thank them for their assistance, for criticism, right or wrong makes you stop and think, or it should. Never have authors pride, which is, never believe your code is perfect, that it will not fail, because sure as shooting, it will prove you wrong. Always believe your code may be fragile. One quick story to prove my point.
As a young staff scientist at DBA systems, I worked on a project that was most sensitive in nature. At each interval, an inspector would come around to make sure we were on schedule and budget, which we always were. Now at the final inspection, a Software test engineer, Jimmy Spruill, came over to discuss his portion of the inspection and the tests he would be running. As we sat there I noticed my system had stopped operating. Mr. Spruill had been intentionally sitting on my keyboard. With a huge smile on his face he announced he was going to red tag my system. Red tag, denotes a failed, do not use part. That started a long and educational friendship. I even took a turn in the testing barrel.
Also, don't get wrapped up with the baby feast syndrome. The syndrome states, "If one woman can have a baby in nine months, then nine women can have a baby in one month!" That comes from the fact that one programmer, given a proper introduction to the problem, will come up with a proper solution, based on their understanding of that problem! If the decomposition proves that more assistance is required, the individual should be able to step forward and promote the additional assistance. The decomposition of the problem issue. Management will always want to throw more human resources at a problem instead of examining the actual failure. The initial decomposition of the problem was understated or not understood.
The rule I have lived with all my life and it has never, ever failed me! KISS -- Keep It Simple Stupid. I see code that is so convoluted, that it would be better to start over than to attempt to debug it. I've done precisely that.
I write object oriented code and wonder where all those great promises went to. How once a library of objects is collected, you would literally just have to connect objects. So, mostly I stick with just good old structured programming. It is the parents of object, rather anyone wants to admit it or not!
Also, I have committed hundreds of routines to my personal library. I've created these routines over the years and have found it to be invaluable when starting a new effort.
Finally, if you wish to use the debugger, I will encourage you to do so. It is one of many tools we will get into. Some good, some not so much! Oh, the fun part. Each of you will submit your solution via e-mail and we will have a guest computer come in and on a video feed, they will perform your steps. Believe me when I say, it gets fun then.
So as your entrance exam, riddle me this:
You are next to a running stream.
You require 4 gallons of water, no more and no less.
You have a 3 gallon bucket and a 5 gallon bucket.
How do you get exactly 4 gallons.
Copyright © 2000 - 2018 All Rights Reserved Have fun; will travel!