The Hard Answer

The hardest answer a systems developer ever has to give is “I can’t do that…” Of course, by that I mean the task is something they don’t know how to do, or involves something they can’t get to. I once had a data intensive task that relied on ODBC for access. I couldn’t hook the ODBC driver to get the information I needed to display a meaningful status indicator. I contacted the vendor for technical advice, because they did have a status bar on one of their database utility applications. The answer I received was “do what we do, estimate the status ahead of time and display your estimated results.” In other words, fake it.

The hardest answer a development manager ever has to give is “I can’t do that…” But, in this context, the task can be performed, but the result isn’t worth the effort. This is a particularly hard answer for a “player manager” like me, the guy who has to make that decision but who also would enjoy writing the code. When I read about the alternatives that I have to solve a problem using SharePoint, I often wonder if anyone ever asks the question “is this worth it?” I am not a big fan of overly detailed cost benefit analysis, but you have to do the math. A feature that is going to save a person 10 minutes a month that will take hours to develop, hours to test, hours to document and some amount of time every year or every upgrade cycle to maintain; is just not worth the effort.

It may not come as much of a surprise to find that I’ve been working in SharePoint Designer this week. Most of what I have to say is positive, I love the look and feel of SPD 2010 and I love the advances Microsoft included in this program. We are working through proof-of-concept workflows on the demo site I wrote about last week. Workflows are the hardest thing to explain to users new to SharePoint and ECM, but it is so easy to show the results. We upload a document; the workflow updates several metadata columns and assigns the next task to the appropriate person – fantastic! The downside of demonstrating workflows is that they look like they were easy to build. Like a newly painted room, the result belies the effort. The usual next step is feature creep.

Human nature causes us to look at something and think of ways it could be better. When you look at a business process that currently takes hours, and you see how it can be reduced to minutes, there is a momentary pause at “Wow!” and then your brain goes straight to “but what if…?” This is a good result when someone points out that a single person is responsible for a task today, but it may be a group next year – OK, we can fix that. The review process turns bad when someone sees that you are updating five metadata columns, but that they still have to update two themselves. Their brain takes them to: “couldn’t you set that column too?

The answer is almost always “Yes!” followed by a babbling stream of consciousness from the geeks in the room that induces eye-rolling among the other meeting members. During this process, the few active manager cells in my brain are doing the math and sounding the alarm. Even as I am participating in the frenzied ad-hoc design session, part of me is saying “this solution is untenable“. What is spewing forth at the table is a listing of development steps. What is not being discussed is the testing, documentation and maintenance associated with that list. As much as solutions have to begin with requirements, they also have to pass the test of value. I am not sure how this story ends ( it will end, see Today & Tomorrow) so in lieu of some profound bit of wisdom, I leave you with a quick sequence of screen shots that might make you laugh.