I’m a programmer. Its what I do for a living. My specialty is HL7 Integration using the Mirth Integration Engine. I am a multi-lingual programmer which is a fancy way of saying that I know several programming languages (don’t worry, I won’t post my CV here).
I also play World of Warcraft. I mention this only because the best example I can use of “User Rage” is on the WoW forums. People rage about how they’d fire the entire development team over some stupid little bug, or something that has really nothing to do with the background code. But sometimes they do have a point. Something passes QC (Quality Control) that shouldn’t.
Someone asked me why it was so hard to write a program that works perfectly every time.
That’s not hard! Its dead simple…watch…
in .NET : label1.caption(“Hello World!”)
in PHP: <? print ‘Hello World!’ ?>
There…perfect code (well, maybe there’s a type, this is untested /shrug). This is some real code. It works.
Programmers are human and we make mistakes (as demonstrated above (did you notice?)). Testing won’t pick them all up….I guarantee it. While the typo might be dead simple….it can sometimes take hours to find and fix it.
When designing software we take everything we know into account. The more complex a project, the greater the chance that something will be missed. Some process that someone forgets to tell us about, or gives us inadequate information.
Then there are the things we do. We’ll run into a road block and make a presumption. We’ll add something thinking it would be nice for the users to have, or not realizing (whether consciously or unconsciously) that we really don’t understand a requirement and coding it anyway. We all do these things.
Diligent testing should pick up all this, but it won’t. Some of these mistakes will make it into the Production environment. This is why software projects have implementation phases post Go-Live where everyone (including the development team) is ready to respond to problems immediately.
Its all well and good talking about this, but lets demonstrate it.
Let’s say you’re a programmer tasked with coding a script to guide a robot driver through an intersection where it has the right of way. You write the following code in the programming language Plain English. This is what you write:
If intersection is mine then keep going
You test it, it works fine and you go for coffee. You come back and you’re asked “What about the other idiots on the road” You go back and write
If intersection is mine AND if intersection is clear of idiots then keep going otherwise stop
You test this and realize that you haven’t told the driver when to proceed. You go through several rounds of testing and finally come up with this…
If Intersection is mine AND
If intersection is clear of idiots AND
If number of pets or children that may dash in front of car unexpectedly < 1 AND
If number of police officers directing you to stop < 1 AND
If construction blocking traffic ahead is false AND
If gas sufficient to reach destination is true THEN
Keep Going OTHERWISE
Stop Until idiots, police, children and pets = 0 Then Proceed to Destination unless insufficient fuel then proceed to nearest gas station.
So, this code eventually goes into production and your robot driver performs flawlessly until one day you find out that your robot driver slid out of control and caused an accident!
You feel horrified and sick. You look at the logs and see something that you didn’t consider in your design, brake failure, its one in a million, but you decide to change your “stop” to a procedure (a set of often repeated commands). You write
Define Procedure Stop(urgency,safedirection)
if brakes fail steer to safedirection, shift to neutral and sound horn, disengage engine when vehicle stopped. If collision = true notify emergency services else phone home.
if urgency is immediate and anti-lock brakes = true then steer to safedirection and apply full pressure to brakes unless anti lock brakes = false then threshold brake
if urgency is immediate and safedirection = 0 then brake, horn and pray
if urgency is fast stop then apply increasing pressure to brakes until rate of stop > distance to target
if urgency is normal then apply slow pressure sufficient to stop in time
That goes into production and things run great. Then you run into other conditions that programmers encounter. No notice of changing conditions. The robot calls you and very angrily chews you out because in the past 3 days it has received 3 tickets for running a stop sign. When you explain that you didn’t know that a stop sign was there the robot yells “Its NEW!” calls you a bunch of names and then hangs up.
No one at City Works knew you had a robot driving a car through that intersection and neglected to inform you of the change….
So, you write some code to accommodate for the new stop sign. Feeling a bit angry about being called names, you add some code that will make the robot roll down its windows and belt out show tunes whenever the vehicle’s speed is less than 30km/hr. Your mouse hovers over the deploy button, but you think better of it and copy and paste the show tune code into a text file in case you change your mind later.
Writing code for complex systems may sometimes sound pretty easy when the process is described, but I hope I’ve shown you that it isn’t.
Oh yeah….in a nod to Isaac Asimov you add a line of code to your robot’s programming:
if danger to humans is true then self destruct
You decide that its better to not tell the robot….because, well, he called you names…