David Stein (Blog – @Made2Mentor) started a neat new meme: My McGuyver Moment. He talked about a time where he cobbled together a workable solution out of a coat hanger, two tube socks, and a Mentos. He tagged me, and so now you get to hear about one of my stunts.
The Problem: The Hell Desk
Not so sure I actually want to know.
Several years ago, I worked for a small software company. Software companies have help desks – support teams who take incoming calls, create incidents, and manage the ticket lifecycle. They report on statistics like how fast tickets get closed, how many tickets are coming in, and which users are calling the most. I was a developer, and I had to interact with the help desk system because tickets would get escalated to us when they looked like a product bug. I spent at least an hour a day working with tickets, sometimes 4-5 hours a day.
I hated the holy hell out of our help desk software, and I’m going to name names only because it’s changed hands & versions since: McAfee Magic Help Desk. The user interface was atrocious; some fields could be looked up with a double-click, some with a space bar, and some just couldn’t be looked up. To get to my own list of tickets, I had to jump through hoops sideways. Heaven help me if I wanted to build a report to slice and dice my tickets. Plus, the whole thing was a thick, slow Windows application that sucked up memory.
I was a really crappy developer, but I was certain that even a newbie such as I could build a better, easier, and faster help desk system in my spare time. I couldn’t take the Field of Dreams approach (build a new one and they will come) because the rest of the company was heavily tied to this help desk software. I decided I’d reverse engineer the database schema, trace its queries with Profiler to figure out what it was doing when it updated tickets, and then build a simpler user interface. Everything would have dropdowns and lookups to make my job as easy as possible.
At the time, I knew three development tools: Microsoft Access, Macromedia Ultradev (producing Classic ASP), and Topspeed Clarion. All three of those could work with the help desk’s SQL Server database, but I chose to build it in Ultradev for selfish personal reasons. I knew that building a web-based version of it would push my skills farther than they’d been pushed, and that it would give me new skills that would be more valuable down the road.
Going Behind Enemy Lines with Profiler
I remember feeling like I was breaking the rules. I wasn’t supposed to be back there, inside the database, tracing every query that the app ran. I was in enemy territory, behind the lines. If I was caught, I was screwed, because I could hose the database by writing records incorrectly. I poked around in the help desk console, adding tickets and editing them, watching every query to see how it worked.
When I was confident that I understood what the app was doing, I started with a simple classic ASP (VBscript) page to list my tickets. When I clicked on a ticket, I had everything I needed on one page to update the status and pass the ticket on to someone else in a matter of seconds. I used it for a couple of weeks – okay, no, knowing me, it was probably only a few hours – and then showed it to the other staff. I ambitiously named it The Buzz, because I wanted some positive buzz around it. I wanted to think that years later, when you wanted to see what was happening in the company, you’d fire up The Buzz.
Bonus points for connecting the head light power with paper clips.
The Buzz didn’t catch on right away in the company. Not everybody was as freaky about user interfaces as I was, and they probably didn’t trust my code too much. (Rightfully so!) Over the coming months, I kept adding in more functionality in my spare time.
One day, our company expanded by one too many employees. Our help desk software licensing was per-seat, and we faced a huge expenditure to buy another block of seats. The maintenance bill was also coming due, and if I remember right, the whole bill would have set us back by maybe twenty grand. My boss decided that the company would switch over to my web-based version instead. I remember being terrified about the licensing implications. Were we allowed to keep using their database? Were lawyers going to come knocking on our door demanding that my VBscript code be burned? Of course, none of these things happened, and my little web-based help desk soldiered on.
Soldiering On Over Time
Over the years, I added more and more functionality into the app, and The Buzz became the company intranet. Whenever somebody in the company needed a new piece of functionality that would benefit from the content of this database, like the tables with clients, contacts, software, or more, we just built it into The Buzz.
Several times during my career at that company, I continued to reverse-engineer existing systems and assimilate them into The Buzz. For example, we had a clumsy supplies-reordering system for our clients – out it went, replaced with a public-facing web site in VBscript ASP integrated with The Buzz’s database. Clients could log in, see their own contact information, see their product list, and click which supplies they wanted to order. Orders were created as help desk tickets and went straight into production. Next up came a workflow system, sending those completed orders on to accounting. I shaved tons of labor off our old fax-based paper-trail system, enabling us to react faster and keep everything in one central place.
I beat on this drum a lot here at the blog, but there’s a few lessons I want you to take away from this.
Scope creep can be a great thing. I aggressively looked for things I could add to my product. I wanted to find things I could automate fairly easily in my spare time, but only things that users would thank me for when it was done. I wanted to build a reputation in the company as the guy who makes jobs easier. It’s a lot easier being an evangelist when your product does things people want. Next thing you know, your manager sees you as self-managing, and gives you more work time to do things you enjoy.
Build things to pass them on to others. Build your code in a way that you can hand off maintenance work or feature development to more people quickly. If you’re the only person who can work on your stuff, you’re screwed – you’re facing a lifetime of maintenance work, keeping the trains on time, and somebody else will get to work on the new hotness. Document your code as you go along. If you think there’s even the slightest chance that someone else might want to interface with your code, build logic into reusable modules like stored procedures. For example, I wrote a stored proc to add a help desk ticket, and it handled the inserts across several related tables. When another dev group wanted their software to automatically create tickets whenever processes failed, all I had to do was point them at my stored proc.
Doing what you love isn’t work. Because I picked the platform, the product, and the people, it didn’t feel like work at all to me. I couldn’t wait for my real work to be over and my pet project time to start. You won’t get an opportunity like this during your “day job” at first because you have to do what the company says. In your off time, you can do whatever you want. Yes, this means after-hours work for you, but it can help you learn and grow. I still remember learning how to embed audio in ticket notes (which were HTML) when we did an April Fool’s prank – whenever you opened one of my help desk tickets, the A-Team theme would start playing. That was the opposite of hard work.
Be ready to answer the question, “What could you do with another person?” If your Skunk Works approach pays off, sooner or later your boss will start hearing all the requests from end users who want more stuff from your time. There will come a point where the boss asks, “I’ve got a lot of people asking for a lot of things. If I gave you a junior coder, what would you have them start on?” To this day, I’m militant about keeping a backlog of tasks so that I can easily justify another head count. This is why the next point is so important.
Starting cheap doesn’t mean sacrificing scalability. Choose a tool that makes it as easy as possible to get multiple people coding with you. I bashed Microsoft Access last week because it doesn’t scale, and that’s true for more than just the Jet storage engine. Two, three, or four people can’t easily edit the same Access file at the same time, each contributing improvements to different parts of the application. Working in a tool like Visual Studio (or at the time, Macromedia Ultradev) enables collaboration.
Who I’m Tagging
I think this meme lends itself more to developers than DBAs, so I’m going to tag a few people who’ve made part of their living building stuff:
Brent specializes in performance tuning for SQL Server, VMware, and storage. He's one of the very few Microsoft Certified Masters of SQL Server, a published author, and a Microsoft MVP. He likes travel, Jeeps, Apple gear, jokes, and writing about himself in the third person. Read more and contact Brent.
Website - Twitter - Facebook - More Posts
