Management Induced Technology Constraints (6)

It’s been eleven years since I started developing professional software. My first experience with turning code into cash came in 1996 when I wrote and sold a shareware application named HotBar. HotBar was a time saving utility for Windows that allowed the user to launch their favorite applications from a bar that hid itself along the top or sides of the screen. The Mac OS X Dock and Window’s Quick Launch have long since replaced the need for HotBar, but back in the day strangers were very willing to mail me $15 to make the nag screen on my software go away.

I was fifteen years old and the Internet was my oyster.

My career as a software developer has come a long way since then. I now run an IT training and consulting company which allows me to turn even more code into even more cash. Through my company I’ve had the opportunity to work with some really talented developers in many different industries ranging from aerospace to zoology. (Actually, “aerospace” is accurate but “zoology” is a lie. “Aerospace to insurance” just doesn’t sound as catchy!) One of the themes I’ve noticed in my career is that no software developer believes that they are working under perfect conditions. Sure a lot of us are working under good conditions, but there’s always something about our work environments that could be improved.

The biggest constraint that most developers face is time. “If only I had more time to implement my dream feature, voice activated drag and drop, into that last revision…”

Other constraints that developers face include limited budgets, limited access to resources and unrealistic expectations from management to name a few. Looking back on things, I didn’t realize how good I had it during my days as a shareware developer. Having yet to refine my skills with women, I had all the time I needed to hack code from the moment I got home from school until the time I fell asleep to Leno. I had no overhead. The only expenses I had were my computer, my copy of Visual Basic and my $15.99/month dial-up Internet access. Ahh, those were the days. (Some of my elders reminisce about the era of punch cards, while I reminisce about the seven days it took me to download the Spirit of Christmas from an FTP site in Norway on my 14.4Kbps dial-up modem. It’s all relative.)

Today my constraints are varied, although most of them come down to time and money. These are common problems with common solutions which I won’t go into now. Today I’m more interested in sharing with you the single most frustrating constraint I’ve witnessed in the last few years: “Management Induced Technology Constraints.”

Before I begin I must admit that this constraint is not one which I’ve personally had to endure. Rather, this is a dilemma that I’ve witnessed a few friends and colleagues go through. As a consultant, I’m usually only responsible for producing a deliverable and am typically free to use whatever tools I desire. Since I haven’t had to endure their pain first hand I’m afraid I won’t be able to speak with the same passion and conviction that they carry, but I’ll do my best to invoke their pain by rubbing paprika in my left eye.

To protect the innocent (and the guilty) I won’t name names, but a colleague of mine works for a state government agency here in the United States. He’s a web developer who works primarily with XHTML, CSS and JavaScript. Most recently he has been incorporating Ajax into his applications. (Which, by the way, is difficult to do well when creating government web pages because of accessibility laws.)

Let’s call my friend Dave, because that’s his name and there are thousands of Daves at state agencies. I dare you to trace this back to him. You’ll never do it. (Hint: It’s not Pennsylvania which is where I call home.)

Dave recently emailed me complaining that he was having trouble debugging a web page that was trying to parse an XML document in JavaScript. The XML document was the response from an asynchronous Ajax request to the server, and his Internet Explorer alert debugging just wasn’t cutting it. I suggested that he download and install Firefox along with the Firebug, Web Developer and Live Headers extensions. If you’re a web developer these tools will forever change your life. If you think I’m exaggerating then that just highlights how desperately you need to try these extensions. Seriously, they’re that invaluable.

Dave installed the tools, and as predicted he fell in love. What used to take him three hours to debug now only took a few minutes. More importantly, what used to be impossible to debug in Internet Explorer was now easily accomplished with Firebug. (Seriously, why does IE always complain about the line a function is called rather than the line in the function where the error exists?!?!) Hours after installing and playing with these tools Dave sent me an email thanking me for my help.

God, this paprika is really starting to burn.

The next day I got a call from Dave. “Hey, Michael. Any idea why Firefox would be missing from my hard drive today? The link to it on my desktop is still there, but the application seems to be completely missing from Program Files.” I had no clue. I suggested he download and reinstall Firefox, Firebug and the other extensions from yesterday. After a few quick re-installations Dave was back on track and ready to squash some more bugs.

The following day Dave called me again. This time his tone was less inquisitive and more, shall we say, unbelievably livid. “Mike.” (I guess he uses nicknames when he’s angry.) “I came into work this morning and found Firefox was missing from my computer again! I was getting ready to re-install when I checked my email and noticed a new message in my inbox with a subject that read ‘Unauthorized Software Detected.’”

Apparently Dave’s organization uses some sort of big brother corporate software that scans hard drives for “rogue” applications such as Firefox and remotely zaps them off the disk. After speaking with somebody else in IT, Dave discovered that Firefox is not approved software due to security concerns. (Because we all know that Internet Explorer is the beacon of security.)

Knowing that exceptions are sometimes made for developers, Dave requested special permission to install these tools on his computer. Again he was denied permission, but this time he was given a different reason. “Since our application’s minimum system requirements include Internet Explorer, it is imperative that you only use IE when developing.”

Although Dave wanted to scream I actually wasn’t surprised to hear this. I’ve come across this before and it always baffles me. Some organizations are adamant about handicapping their developers by only letting them use the tools that their users employ. This makes about as much sense as telling a chef that he can’t use a spatula because when the diners eat those omelettes they’ll only be using a fork and knife!

I consider developers to be crafstmen and craftswomen just like many other skilled professions and it is vitally important that they be using the right tools for the job. Using the proper tools not only allows developers to be more productive, but it also keeps them happy. Happy workers lead to happy code, and happy code leads to happy users. Despite the obvious-to-me reasons for allowing developers to use proper tools, organizations come up with a number of reasons to prevent this from happening. Some of the reasons that I’ve come across include:

• An aversion to open source software. Many companies are afraid to use open source software because they either fear that some 13 year old hacker from the Netherlands has slipped a back-door into the code, or they worry that they won’t have anybody to sue if things go wrong. Other companies like the support that comes from paying loads of money to a software company, but I’ve always believed that if you hire good developers in the first place they won’t need much support when working in open source. I once dealt with a company that wouldn’t let its developers use Eclipse because it’s open source. Instead, they shelled out thousands of dollars on WebSphere Studio Application Developer (WSAD, although it’s now called Rational Application Developer) perhaps not even realizing that WSAD was built on Eclipse!
• A fear of the latest versions. This one I can understand. Nobody wants to be an early adaptor of new software, because we all know that the first users are really nothing more than beta tester guinea pigs. That said, there’s no reason to force your developers to be programming in Java 1.3 when we’re already up to Java 1.6! Honestly, you can’t even parse XML in Java 1.3!
• A lack of money (or so they say.) As far as software is concerned, unless you’re working in a very specialized field, most of the powerful tools are either free or affordable. Eclipse is free. Subversion is free. JBoss is (usually) free. MySQL is (usually) free. MyEclipseIDE is dirt cheap. Microsoft Visual Web Developer is free. Hell, even Visual Studio Professional edition only costs $799. When I think of expensive tools I think of things like Oracle, ClearCase and WebLogic. When it comes to tools like these, if you need them you usually have the money. If you don’t, there’s free alternatives. My point here is that a lack of money shouldn’t hurt you when it comes to software tools. If a manager uses this excuse then he or she hasn’t done their homework.

  However, a lack of money can hurt you when it comes to hardware. Have you ever seen a C++ programmer squinting their eyes on a tiny 15″ monitor? Many of them do! Have you ever seen an old 486 50mhz machine wired to run as the corporate web server/database/firewall? (Please, you’ll waste more money in man-hours having to reboot the poor thing every five hours than you would in buying a decent server.) Have you ever struggled with a DB2 database that took 2 minutes to return a simple query because it was forced to run on a machine with only 1 gig of memory? For Torvald’s sakes, memory is cheap these days! Upgrade! Almost every single hardware request I’ve seen a developer make can be cost justified. Heck, even Aeron chairs can be cheaper than toilet paper. If you mistreat your hardware it will mistreat you. If you mistreat your developers, not only will they mistreat you but they’ll also leave for greener pastures after they do. Baby your hardware and baby your developers better than you’d baby a Lamborghini Murcielago, and they’ll pay dividends in return. (One in the form of very reliable software, the other in the form of a very reliable string of one night stands.)

• “If it’s good enough for our users, it’s good enough for you.” As mentioned above, this just doesn’t make any sense. You don’t take away the dentist’s drill because little Johnny doesn’t use a drill at home. This is the exact type of policy which will filter out good software developers and trap in the bad ones who don’t know any better.
• Nancy in HR ruined it for everybody. Because Nancy in HR was caught posting her resume to Monster.com on work hours, and Jim in accounting was caught posting his picture to AFF (if you don’t know, don’t ask) management has decided to crack down on Internet usage. I once taught a corporate training class at a company whose proxy server completely blocked Wikipedia. Since Wikipedia includes content on everything, and NSFW is a subset of “everything”, management figured that the easiest thing to do would be to block the site all together. As far as I’m concerned, if you block Wikipedia you might as well block the entire Internet.

  At another company I once worked at, I tried to access an XML Schema tutorial hosted at Angelfire. Not only was that site blocked, but the proxy server also gave me a message stating, “Worthless Lifestyle.” Were they making a statement about XML or about Angelfire? I have no clue.

  My point here is that while it might make sense to restrict the Internet access for non-technical employees, it can be a death sentence to a software developer. To a software developer, the World Wide Web is their lifeline. The answer to most bugs and perplexing code questions is inevitably going to be hosted on a web site that mispells “best practice” as “breast practice” and is therefore blocked. You pay your software developers too much money to be wasting their time, and more importantly, too much money to mistrust them. Besides, geeks are smart people and they’ll just end up figuring out a way around your limitations.

In conclusion, don’t let a poor management decision become a technology constraint. Developers have enough to worry about as is. Management’s responsibility should be to nurture its developers, not drive them to the competition. Software developers typically have a lot of employment options, and even if you can’t offer the best compensation you should at least offer them the best working conditions. The technology that a programmer works with makes up a large portion of their working conditions, and that’s sometimes difficult for non-technical managers to realize. Developers were hired for their technology expertise, and they should be trusted when they request a software application, hardware device or Internet access. (Also read as, “Don’t interrupt my programming and I won’t interrupt your golf game!”)

My rant ends here. If you’ve experienced technology contrainsts brought on by management, please share your stories in the comments below. In the meantime I have to run. My eye is starting to swell itself shut.