There are two types of people in the world: Those that divide groups of people into two types, and those that don't...

Lately, I've been thinking about two types of developers (or coders).  Or more specifically, two types of developer attitudes:  The PC and the Mainframe.  For the purposes of this article, I'm using PC in its generic form for personal computer, lumping both MAC and Windows into the same bucket.  You can even throw in some Linux for good measure.

So what do I mean by PC and mainframe attitudes?  Well, if you're old like me, you remember that businesses used to run on mainframes and minis which were stored in large climate-controlled data centers, and everyone, including the IT guys, wore suits.  And then the PC burst onto the scene like a brash teenager that knows everything and makes a bunch of disparaging remarks about the old guys who are stuck in their ways and slow to change.

A lot of developers are the same way.  They think that whatever the latest, fastest, (most Agile?) technique is, that it is the best choice, and they are so fast or so good that they put those old guys to shame.  The PC guy or gal will seemingly crank out a lot more code than the mainframe dude in the same amount of time.  And on the surface, they appear to be comparable in quality.

There was some truth in the PCs' claims.  For may tasks they were faster and more dynamic, and several tasks were better suited to the individual desktop than to the big data center.  For example, it is better to have your Excel spreadsheet sitting on your local computer while you run a series of what-if analyses in a matter of minutes, rather than having to wait for the nightly batch run to return the results of your first IF.  But they also had their drawbacks, some of which we are still ironing out today, like more frequent crashes, and security concerns.  They're great for browsing the web and initiating online banking transactions, but the actual heavy-duty activity of moving trillions of dollars in and out of millions of bank accounts, and reconciling it all, is still handled by the mainframes.

I can hear you saying to yourself, "so what does that have to do with anything?"  So we go back to the statement that on the surface, the results from the two appear comparable, and every manager would rather have the faster, more productive developer on his team.  But underneath, the mainframe guy (or gal) has built a solid, secure, recoverable infrastructure that can handle all the unexpected events that always seem to come along at the worst possible time.  If it's a batch process, the PC guy's code works, as long as everything works.  It might even work as long as the only problems are the few things that the PC guy happened to think of.  But the mainframe approach has process managers built-in that can suspend the process and rollback if necessary.  The mainframe approach logs these events so they can be analyzed later and perhaps additional structures put in place to prevent or properly handle them without suspending the whole batch.

In other words, the mainframe attitude is to build something as bullet-proof as possible.  It takes the time to build in the extra security and management features.  It reduces the chance of getting a frantic call at 3 AM, or even an automated page or text message.  It looks for ways to provide a more complete solution.

Each has its time and place.  For may development tasks, the PC approach works great.  But for many DBA tasks, you want the mainframe attitude.  Ideally, whichever is your default, you have a healthy respect for the other.  And if you play multiple roles, which is happening more and more these days, you need to be able to switch from one approach to the other on-demand.  That's no easy task, which is one of the reasons why so few people are successful at it.

So back to the original question.  Are you a PC?