Mike-O-Matic

IT culture is one of those things that is difficult to quantify but easy to feel. So much of what we do crosses multiple disciplines, and it is easy to think our workplaces are as nuanced and multi-dimensional as we are.

Not so.

In my time working at different companies and organizations, I have seen 3 distinct cultures:

1. The SQL Squad: These places tend to think of everything in terms of databases. Tables, views, stored procedures, CRUD… they can’t get enough. If you don’t have an administrator in your pocket (usually through bribes of some sort) you can’t get anything done. Signs your workplace may be part of this group: You use Oracle or DB2, know what XSQL is, or threaten to REVOKE friendship on all those who oppose you.
2. The Application Formation: These guys like application frameworks a lot. They swoon over Rails and salivate over CakePHP, but always end up building their own systems anyway, just cause they can. When they use databases, they see them as little more than fancy filesystems. One database user is all you need, ever. Signs your workplace is in this group: You use Ruby or PHP, think MVC is the way to be, or think coffee extends beverage and implements caffeinated.
3. The Design Division: This shop places an emphasis on design and front-end functionality. They are on the forefront of new web design practices, and were doing AJAX back in the ActiveX-only days. With graphics guys running the show, not as much attention is paid to the back-end systems and maintainable code, since it is all about pushing it out and getting on to the next project. Signs you may be in this group: You see Flash as a viable replacement for HTML (sometimes), include Photoshop in your developer baseline config, or compete with your coworkers in CSS Zen Garden submissions.

There are some organizations that are able to cover multiple categories, or have several different groups within a single department. Even then, though, there is usually one that is dominant.

Why does this matter? Glad you asked.

If you are a developer working in a culture that is different from how you approach technology, you are likely to butt heads a lot with your coworkers. It’s sort of a square-peg-in-round-hole situation.

Once I was working at a place that was squarely in the SQL Squad camp. Our inventory management software was very feature-rich, but was overkill for many of our customers. As the person who handled all of our customer support, I was acutely aware of this pain.

“What the hell is a Master Item?” they would ask. “Why can’t I just add a jar of pickles?”

The solution to this seemed obvious to me: Come up with a way of hiding fields and functionality that users didn’t need to see. Change text on the site to things that made sense to different target audiences. 3PL providers will see “Master Items,” lunch ladies could see “Products.” Provide customizations on a per-customer basis.

Things weren’t quite so easy. Being a database shop, the company built the software to make extensive use of CRUD privileges. Every application user was also an Oracle user. If a user couldn’t create new items, they wouldn’t be given CREATE privilege on the ITEMS table. Easy. Unfortunately, this didn’t allow much customization on the front-end, and they certainly didn’t let you get granular enough to hide certain fields from certain users.

When I brought up the idea of handling permissions at the application level, my managers looked at me like I was speaking broken Greek. How could we possibly do that? Then any user could modify data in the database! If they ever figured out their Oracle password and hacked through our Cisco firewall for some reason, they could mess up everyone’s data! The humanity!

It isn’t so much that what they were saying was incorrect; it almost certainly wasn’t. It is just that their priorities were different than mine. Things that I valued highly (such as user experience and maintainable, consistent code) were much different than the things they valued highly, such as absolute data security and an elegant schema design. Software is all about choosing between varying tradeoffs, and the culture of the workplace often determines which tradeoffs are acceptable.

Til next time.

Subscribe to this Blog!