Climbing out of the morass; chipping away at obstacles

My current chores-and-knitting audio book is Blind Descent by Nevada Barr, which is set in Lechuguilla. The story’s murder could be a metaphor for my experience working with the current Visual Studio technology. The non-billable time may well kill my business and livelihood, but I’m not ready to give up. So, today, I am thinking of the expedition as the better, somewhat less bleak, metaphor. Simply trying to wrap my head around add-ons, toolkits,  products, domains, and appropriate uses to assess the viability of any tool has been very much like journey to the center of the earth.

  • Squeezing through spaces so narrow I can’t look ahead to where I’m going? Check.
  • Navigating huge spaces filled with refrigerator sized obstacles? Check.
  • Rappelling down narrow shafts with knife sharp protuberances? Check.
  • Climbing past fragile features? Check.
  • Doing all this in utter darkness except for the questionable beam of my own intellect? Check.
  • All sense of direction lost? Oh, my, yes.

Fortunately a long-time friend of mine is in town for the annual Microsoft Most Valuable Professionals Summit. Reluctantly, I asked Kathleen Dollard to review my project plans for two customers who’ve been waiting patiently for three projects. Lately, I’ve missed my own time as an MVP, not only for the SWAG and camaraderie, but for the ability to plug into the internal state of MS development teams.  She can’t divulge NDA information, of course, but she has an extensive breadth of experience. Research is part of her job, so she tries, as much as is possible today, to keep a broad overall view of the programming landscape. Like me, she’s practical, believes technology serves customers (not the other way-round), and is willing to look outside Microsoft for solutions and examples of good practice. I was reluctant to ask for her help because she makes her living mentoring and consulting. Luckily, she was willing to work for breakfast, dinner, beer, a room, free wi-fi, and all the cat hair she wants.

She helped me tremendously, as have a few other references that are starting to come together as the most recent revs age. In short, she reassured me that, no, I am not yet senile. .Net programming is hard. Really hard. In addition, the programming landscape is in such a state of flux and tools so nascent that choosing an approach today that will be current in 2015 (one requirement) is a tough call. We went through various options, ranted about the general state of programming, drank wine, beer and ate soft tacos from Taqueria Guaymas, ranted some more, and wrote some code. Kathleen is, as we say, good people.

I’m reawakening this slumbering blog for two reasons: 1) I still believe writing helps me think better, and I’m finally at the point that I can fashion sentences that are, at least, coherent; and 2) to fulfill my promise to Kathleen to share my experience. Part of the joy of being a Visual FoxPro developer was the tightly knit, experienced community. Collectively, we knew just about everything there was to know about the product, how to use it well, what to avoid, who to listen to, who to ignore. I still believe the best advisers are programmers who write live, production software. As smart as the folks are at Microsoft, and they are,  field experience will always be more valuable for defining best practices. I say that because I believe any best practice has to take into account the entire scope of a project with heavy emphasis on deploying deliverables and measuring how well applications work for the customer.

There is a wealth, or maybe welter would be a better word, of advisory flotsam on the Internet seas, and I don’t want to contribute to the noise. I want to document what I’ve found to be helpful, obsolete, or gratuitous. If anyone believes this blog is too much noise and too little signal, let me know in comments, please.

Meanwhile, as I sort out my thoughts, concerns, trials, and decisions, please feel free to note your own thoughts. I told Kathleen at one point that I don’t see myself as particularly special. If I’m struggling with something, have a question, or want a feature I know there’s someone else who feels the same. It doesn’t mean that my point-of-view is viable or relevant, but it does mean it might need addressing. Because I’m also not a complete idiot. That’s a mantra I’ve been repeating to myself lately. I am not an idiot; this stuff is hard. I’ll cover the following broad areas: vocabulary, technologies, helpful links, wishes, and ruminations on the state of independent programming.

I like feedback. Don’t be shy.

Advertisements

Email is not flawed, part 2

Monday, I criticized the idea that email should be used for only data and facts, because email with emotional content “is so often misunderstood” according to Mr. Edward Muzio. As if facts can’t be misunderstood or that the written word can’t communicate emotional content effectively.

As Mr. Muzio points out, we communicate through more than words. Tone and facial and body expressions contribute to meaning. So do pheromones. Most of us are unaware of this while we’re speaking. Often communication fails [1] no matter what medium is used, and even if people have a common history or culture. I contend that misunderstandings are more common than we suppose. Fortunately, we are unaware of many of them.  Blaming email for the failures that result from misunderstandings is like a prospector failing to find gold and blaming his mule.

Redundant communication systems, plasticity of meaning, and the relative unimportance of most of our communication saves us from more terrible consequences than we already have. Most everyday communication is mundane, without mortal consequences. Plasticity and redundancy means we can understand the gist of what someone is saying without having to understand it exactly. Normally, we understand well enough, if not perfectly.

Know What I Mean?

Whatever medium we use, misunderstandings occur for any number of reasons. I find they occur most often because at least one of us has made a bad assumption about the other person. Common assumptions are about a person’s state of mind, willingness to understand, ability to understand, and veracity. If I assume you are telling me the truth, and that you want me to know something, but you’re lying or you don’t really want me to understand, well, there’s a problem. If you assume I’m really listening to you and not thinking about lunch, or that I have the vocabulary or experience to know what you mean, then there is, again, a problem. Most of the time we don’t have the inclination or wherewithal to analyze our attempts. However, if what you have to say is important, it does behoove you to consider the medium as well as the message.

Ethics, Shmethics

Have you every burned out at a job? I mean “burned out” with flames, explosions, and smoke? The works. One of those life-changing, crashing-to-Earth, watershed moments that takes years to understand? I have. I’m not proud of burning out, and I don’t recommend it; but I will say it was…instructive.

I burned out after working very long hours under some very unpleasant circumstances for several years. I wonder if all martyrs are tiresome to be around? I must have been, because, when the break finally came, my best friend said to me “up to a point this was noble, but now it’s just stupid.” He was so very right. I’ve come back to this phrase several times over the years.

It’s come up again with regard to business ethics. For some years I’ve been been adhering to the spirit of a long expired do-not-compete agreement. The choice has been easy to make until recently. At about the same time another event transpired that showed the other party doesn’t feel bound by this non-existent agreement. (See the martyr rearing her irritating head, here?)

I think I’m so fearful of being unethical that sometimes I’m just…silly. I won’t say stupid, because I’d still rather err on the side of respecting another person’s patch, than doing something that hurts them. Besides, I believe ethics are what one has even if no one’s looking. They are the difficult choices.

I suspect I overthink a lot of choices by considering more than the written contract. How about you? Do you stick to the contract? Do you use do-not-compete agreements as part of your contracts? Do you teach your clients about them if they don’t know about them?

Not yet Cease & Desist: Am I violating Trademark?

I received an email this afternoon that someone believes I’m violating his trademark on “Pixel Dust Productions” by using “Pixel Dust Industries.”

That may be, though I prefer to not just take the word of a stranger. I started using PDI in 1998 when I became a sole proprietor software developer. I’d really rather not have to retool everything, but of course will respect trademark law if need be.

Have any of you been the subject of a similar notice? If you have any tips, I’d be delighted to hear them. For now I’m off to bone up on trademark law.

Always on the hunt for document management

Document management is one of those software domains that seems to offer choices ranging from:

  1. nothing, which isn’t great for disaster recovery, or
  2. a few mid-range solutions that are affordable, but have fatal flaws–usually performance-related, or
  3. several mind-numbingly expensive “enterprise solutions.” [1]

The last enterprise document management system I reviewed cost upwards of 100K just to put in place. That didn’t include customizing what turned out to be a SQL Server backend so that it would actually understand a particular company’s documents and their relationships. Nor did it include the annual licensing fees, which I’ve blocked from my memory forgotten. I have no doubt those systems work well for companies that can throw hundreds of thousands of dollars at a problem. And I know that some systems really do need such a significant financial investment. I’m also highly in favor of profits, being a businesswoman and what with cats to feed, and all. Nevertheless, it was so not the solution for a client of mine that it wasn’t funny. [2]

My client eventually settled on software that could be pretty good, but is seriously hampered with what I consider to be an perfectly ordinary number of documents for a small-to-midsized business. Which, in my eyes, is a fatal flaw since the pricing targets that size business.

Document management is one of those pieces of software that we should know how to build so well that by now there should be off-the-shelf software, ready to work for most businesses [3]. It shouldn’t be necessary to hire a programmer, but only necessary for business people, anyone, to identify documents and how they relate. Connecting a scanner seems to me to be most complicated issue. They can be finicky. In any case, there is no good reason why we should even be thinking about writing custom software except for unusual circumstances that beg for demand blood-sucking consultants more sophisticated solutions.

(Cue theatric sigh.) So…if you know of an affordable document management system, please post a comment. I’d be glad to also hear of your experiences with document management sytems, or enterprise solutions, for that matter.

[1] I’ve come to suspect “enterprise solution” really means “lets take these suckers for every penny we can get.”

[2] The salesman didn’t even bother to return my client’s request a bid so that he could discuss it with his board. I guess we just weren’t his type *spit*.

[3] Accounting software is another.

Effective Email

Robert Scoble recently wrote about a two-minute-rule for processing email. One option for dealing with email overload is to delete any email that requires more than two minutes to reply to. Bah. That’s an emotional and inappropriate reaction to a real problem.

Leaving aside the insulting nature of the suggestion it begs the question. Does the technology serve us, or do we serve it?

I don’t have to deal with the volume of email Robert does, so I understand that his issue is much more pressing than anything I’ve faced. The principles, though, should hold.

First, why do we feel we have to reply as soon as email comes in? Do you find yourself reacting to every incoming? Don’t. Sort your email as it comes in. For example, I use Microsoft Outlook’s rules to sort incoming mail by sender and subject. Emailed error reports and any email from clients gets the highest priority with a desktop alert. A few senders trigger sounds, too. For example, from the network manager who may be sending me an email about the network in the evening when I’m not at the computer.

Emails from friends are sorted into a friends folder which I can easily scan when I want to take a break from working. I don’t have to have coding interrupted for emails that aren’t vital.

If a client’s email requires a complex reply, I’ll call them, and email a summary of the conversation so later we know we talked about the original email.

Lastly, I try to be conscious of what I send. Is the email clear? Do I have a sensible subject line, and do I clearly say what I want the recipient to do? Should they reply with an answer to a question? Do I want them to simply have the information for their records? Am I asking several unrelated questions in one email? If so, I break them out in to seperate emails. Do I include a unimportant information? Someone might be able to field one of my questions immediately, but they may need to get to others later. My failing is I’m inclined to make things really complicated. It’s odd, but more words can actually impede understanding.

I assume if you send me something, it’s important to you and I’ll acknowledge that. If I don’t have time to respond in a way that you would want, I’ll let you know that. I’ll never just delete something because I’m too busy. And, if I ever do, just remind me to get my head outta my butt. :-)