Recently, I read a blog post by Andy Leonard on his SQLblog.com titled Long Poles and Critics. In this post, Andy discusses the importance of not being too quick to criticize other’s work when he’s called in to complete or extend software reporting projects.
Almost by definition, consulting is an arrogant profession. SSRS consultants are paid considerable sums to solve other people’s problems. So being quick to criticize is endemic.
Still, I agree with Andy. I’m careful to give those who’ve come before me the benefit of the doubt. But it’s not because I don’t know the full story, as Andy writes. It’s because I know that, while I’m proud of most of the work I’ve done, anyone looking at some of my projects would scratch their heads.
If you were to ask me, “What were you thinking?” I could tell you exactly. Here are some examples:
1. The Simple, Quick Solution That Took Over the Universe
This scenario has come up more than once, most recently a little over two years ago. We had done a bunch of data integration and reporting work for a client. Then they asked us to build a simple tablet app that could replace a spreadsheet they were printing and filling out by hand.
Our software development services were focused on data work. So, building tablet apps for the client’s warehouse was a little out of our ballpark. But the spec was simple. So we said okay.
Eight months and around 1500 billable hours later, the “simple spreadsheet” app had become what we (only half jokingly) referred to as their new warehouse management system. Oy!
2. The “We Have to Go Live” Work Around
Another fun situation. I had a role in a Lawson implementation project, focused mostly on converting data and some customization. Other consultants were in charge of writing a major interface between the company’s AS400 system and Lawson on Unix.
Two weeks before going live, the client asked me to test the interface. It took me five minutes to break it in two. It wasn’t going to work.
So, yes, I did criticize the other guys. But then my own solution, which I had to put together with whatever was available, was not my prettiest work. That’s what happens when Perl and COBOL are the only languages you have, the setup is beyond complicated, you have to work with a second rate integration tool, and time is up before you start. But we went live on schedule. And my workaround worked.
A few months later, I was able to clean it up. But anyone who’d seen the code in the meantime would think I was on drugs.
3. The Only Guy to Get Anything Done
This story isn’t about a program we wrote, but a program we had to upgrade. Essentially, we upgraded the existing “poor man’s workflow.” The workflow started as a RPG program. Which called a Java program. Which sent emails to users in Lotus. Who clicked on the email to approve changes. Which sent data back to Java. And then back to RPG. Which called an API in the ERP system.
It wasn’t pretty.
But the final result was highly useful to the business, and the program ran pretty well for many years. And the client’s IT department had the tendency to design beautiful solutions that worked in PowerPoint and nowhere else—so the client had no real alternative.
With these experiences, I find it pretty easy to limit my criticism of other’s work.
If people claim things that are absolutely false, then I’ll call them out on it and won’t be shy. But I won’t critique things because they aren’t elegant or don’t show best practices. Because I remember much of what I’ve written. And it isn’t always pretty.