Robert on Software Development

Yesterday I had lunch with two colleagues. As we chowed down on pulled pork and spiced apples, we talked about what makes something “enterprisey” and the scenarios in which going with the “right option” isn’t always the best option. It was a good lunch.

It seems like in every conversation about work in which I’m involved, the topic of SharePoint arises. Most people hate it and are aghast when I tell them that I work with SharePoint and actually like it. Of course I can understand their frustrations with SharePoint; it can be a real pain to use, especially when you don’t know what you’re doing (and it’s so easy to not know what you’re doing). When things go wrong, they go spectacularly wrong. The API is difficult to code against, the documentation is nearly non-existent, the tools for administration are a joke, and the system requirements are ridiculous. Add all that to the enormous licensing costs and you have to scratch your head while you wonder aloud, “What the heck are you thinking?”

But that’s just it: SharePoint is a challenge, and when it’s done right, when you deliver that piece of the application that SharePoint really excels at, you end up with something that feels about as close to magic as you’re going to get. Take the time to master SharePoint, and you have a tool that sometimes feels like it inherently understands your business processes. Have documents that need approvals? It’s built in. Need to store multiple business documents in a shared location with metadata to separate them? It’s built in. Need to kick off some kind of process when a piece of data changes? It’s in there. You can develop a custom ASP.NET application, host it inside SharePoint, and take advantage of what WSS and MOSS 2007 offer. That’s what we’re doing at my current customer, and each time I add a new piece of functionality to the system, such as a document library, I solve a complex business problem that formerly plagued them. The “wow factor” from that is intense.

As I work with SharePoint more and more, and embrace its quirks more and more, I remind my customers of the need for a dedicated SharePoint person on the team. That’s the thing about SharePoint: you can’t just install it and walk away. You need someone to tune it, optimize it, keep it running, and support the people who use it. It’s like a DBA, but for something a little more specialized.

Find the right person to do this and you’ll find yourself singing SharePoint’s praises. With time, the pain and suffering will all drift into the haze of days gone by.

Not too long ago, I was working with Microsoft Excel and had to write some macros. I finished up my work in Excel but left it open, and several hours later, I came back to my computer and the Visual Basic code editor was still open, minimized along with Excel.

Seeing that Visual Basic window minimized to my desktop brought back a wave of emotion and memories. About 14 years ago, I started working at a crappy mortgage services company. I was 20 years old, futureless, prospectless, but not hopeless. I was making $6 an hour as an administrative technician (I created WordPerfect and Lotus documents). I had heard about this thing called Visual Basic, which allowed you to easily create programs for Windows. I had written BASIC code a lot in high school, and I knew a lot about computers, so Visual Basic sounded very appealing to me. It was my chance to actually enter a career, and I was quite passionate about computers and technology.

I went to the mall and bought Visual Basic for Dummies. It was so Dummied that it didn’t show how to do some important things (for example, showing a form; for a while, I used form1.Visible = True and form1.Visible = False to show and hide a form, but I eventually discovered form1.Show and form1.Hide) but I didn’t know any better. My wife and I were quite poor, so we didn’t own a computer. But I was determined to learn Visual Basic and get a job as a computer programmer. I read that book over and over, at least five times, cover to cover. I memorized every little detail, wrote code on paper to practice my style, and dreamed daily about my chance to be a programmer. I would even hide out in the bathroom at my job and read the book, imagining myself writing code for something important.

Someday.

It’s weird to romanticize computer programming, but that’s how big it was to me. After I left the mortgage company in January 1995, I went to work at a utility company in Austin, where I was responsible for creating an Excel workbook that tracked all the materials ordered for building substations (exotic, I know). It was then that I got my first chance to code in Visual Basic, writing macros for this huge spreadsheet.

And here I am, almost 15 years later, realizing the success that I started with that Dummies book so long ago. I could be a pessimist and say I haven’t gotten anywhere, but truthfully, I’ve accomplished all of my career goals. I’ve been promoted all the way to architect, I’ve published books, I’ve led teams, I’ve shipped products, I’ve traveled, I’ve been offered speaking engagements, and best of all, I’ve helped other young people get started in this business.

I’ve had my fair share of failures, too. Internet companies, technologies (OS/2? What was I thinking?), missed opportunities, and I’ve learned from them all.

So now when I look at that little minimized window, I feel appreciative for what I have, and the opportunities I’ve been given. Now, I want to do something truly great.

There’s a term that comes from online games known as grinding. This term is used to describe a repetitive activity intended to accomplish some goal. For example, you might find yourself repeatedly killing a certain type of creature in the hopes that it’ll give you a particular piece of loot. That’s grinding.

The point of bringing that up is to say that I feel like I’ve been grinding a lot on a particular task at work. It seems like a pretty simple task, involving SharePoint document libraries and Word documents, but something about the whole thing just isn’t sitting right. Not yet. I’ve spent a lot of time on my whiteboard, mapping things out. Each time I’ve come up with a solution, I go into SharePoint and figure out why it won’t work. Content query web part? Nope. Document library web part with querystring filter? Nope. Individual libraries for each user group? Nope.

And so on, and on, and on, until the end of the day comes and I throw my hands up in the air in defeat as I trudge out to my Jeep for my mercifully short commute home through downtown Des Moines. Yet I still have the specter of the problem hanging over me, taunting me, urging me to just stay in bed and pull the comforter over my head until SharePoint somehow magically solves itself.

As a grown up, I have figured out that such solutions aren’t really solutions at all, and I do indeed have to face the music, so to speak. The first step to overcoming the demon is to admit that I am the one with the problem: my skills in this particular area aren’t strong enough, so perhaps I can’t figure this one out on my own.

Tomorrow I’m bringing in another set of eyes to work on the problem with me. Hopefully we can collaborate effectively and devise some kind of solution that will solve the problem without taking forever to implement. This guy’s SharePoint knowledge is next to nil, but he’s a smart developer so maybe just talking about the problem will give me the eureka moment.

I’ll let you know.