Item 2: It's not so much a production server...

as it is a really really important development server.

Most people in IT will immediately understand this frustration. A common
simplified view of complex enterprise IT is that production servers are
only those that production data flows through.

In itself that's not a bad definition of a production server, but it is
incomplete. What about the servers that those "production servers" depend
on? Aren't those also production servers?

A reasonable view of configuration change management says that those support
or dependent servers are also production servers and together with the
"production servers" make up a production environment.

A Dave does not see this. He perceives only machines in a production data center
and only those through which production data flows as production servers.
The following story provides an example of what can happen (for those that cannot
already forsee it) when production servers are made dependent upon a "not so much a
production server".

Bob was a very bright developer. And motivated. He often went off on his own
time and implemented impressive solutions and tools. These tools far too often
quickly became standard tools for our group. As such they became heavily relied
upon.

All of this is good, but Bob had a habit of doing things his own way - and not documenting
much. In this case, although we were a Microsoft house he built a tool on Linux, for no other reason then Bob liked Linux. By the way Linux was not approved or authorized for use in the Production. This tool was very impressive in the way that it handled processing stories. Over time the
tool became a service that several soon to be production critical components depended on.

This sounds great and it should, but it soon won't. When these critical components did finally move into a production environment, no one bothered to ensure that Bobs service got hosted in a true production environment, as opposed to the "not so production environment" running under Bob's desk. Since there was no firewall between development, pre-production and production the service could
still be reached (on Bob's desktop). As long as Bob's computer ran, everything was
fine.

As a testament to linux (and Bob's capabilities) the service ran flawlessly for
several years. Bob eventually left the group and gave his hardware including this
"not so much a production server" desktop to a co-worker . This transition happened
at the end of the day Friday and by Monday was up and running. Production was
going along just fine.

Then it happened. The co-worker decided that since she had not needed to access any of the servers for development reasons, they could be retired and the desk uncluttered. Logical enough, so she turned off all the computers that Bob had given her for "safe" keeping.

Within moments, the calls started coming in, multiple "PRODUCTION" systems were failing, with out a obvious reason. After everyone associated with the failing systems are in panic mode racing around looking for the causes the outage, someone says "We should call Bob he knows alot about that system.". At the sound of the name Bob, a light goes off in the co-workers head, she strolls back to her office reaches under their desk and turns on the one computer
which Bob told her was pretty important moments later every thing is back up and running.

Later and reasonably concerned she calls and asks Bob why he gave her a production server. His response: "Its not so much a production server as a really important development server." After all
it didn't actually process production data and provided information to do so. And it was too
difficult to get a linux machine into our production environment.

In the end, lets remember one important thing. If a production server talks to it, its a
production server. There is no such thing as "not so much a production server".

DON'T BE A DAVE!

Item 1: Rmvng vwls frm vrbl nms svs spc. Wh crs bt rdblty?

That's right you read it. Well probably not. That is the point.

Dave was a firm believer and enforcer of the idea that saving
disk space was paramount - and removing vowels from variable and function
names saves space (disk space). And that gives us the title. The reality was
that you removed vowels (except in a few cases) and some constanents.

Ingenious idea, right? Who really cares about readability ("Wh crs bt rdblty" for
those that haven't figured it out yet), right? Everyone except a Dave. Why?
Dave wrote, and remembers it. He doesn't need to read it. If someone else
needs to understand it, ask Dave!

But we digress...

Let's look a little closer at this. At first glance, there's some logic here -flawed
as it may be - but there is logic. Technically each character taken out of a file
saves one byte of space on a hard drive. Therefore you saved one byte for each
vowel removed from a variable of function name.

So how much space do we really save? Lets look at a simple example. Let take
a function that is supposed to return the current time zone. Insisting on readability
we would call this function getCurrentTimeZone(). Dave would insist (and sometimes
change the name for us in our specialized version of a shared source repository(but thats another story)) to GtCrrntTmZn(). By our calculations Dave managed
to save us a grand total of SEVEN bytes!

Here are some other examples of variable names:

Level => lvl saves two bytes
Name => nm saves two bytes
LevelName => lvlNm saves four bytes
PlayBack => plyBk saves three bytes
comPort => CmPrt saves two bytes and confuses everyone...

Disk space hasn't really been an issue for some time. Bear in mind Dave didn't
say this in the early eighties - he was enforcing this practice in the early 21st
century. Ok at that time, terabyte hard drives were only available in a programmer's
dreams. But even then 4, 6, 8 GB hard drives really existed!

In the end lets learn from this. Saving a byte (approximately .0000000125% of an 8GB
hard drive) does not help as much as the reduced readability hurts.

Don't Be a Dave!

What does it mean to be a Dave?

It’s a term that we coined to refer to someone who is incredibly intelligent but disregards good practices because he thinks they don’t apply to him or just thinks they are a waste of time. In our case it is specific to IT or more specifically software engineering.

To understand where the phrase came from one must understand a little background and some of the supporting characters or at least the main character. Dave was a guy we worked with some time ago. He was incredibly intelligent in many ways but lacked formality in software development. He could crank stuff out, but it was very unreadable and undocumented. It was all good if he had to support it, but if anyone else had to touch it – pray for their souls.

All the points or items we mention are real world events. Names have been changed for anonymity, but they were done by real people. Most were committed by Dave, but not all. When appropriate we will take a few sentences to explain the supporting character. In the end the lesson is the same – Don’t Be a Dave!

In other words, a Dave is a nice, friendly, intelligent, hard working and productive co-worker. At the same time his lack of formality and hard headedness make life difficult for the rest of us. So... Don't Be a Dave!