software Tag

Data Charts It's a funny thing about Salesforce developers. Many of us really dislike change, even when we know very well it's necessary and worthwhile. Why? Too often, changing an application is like re-routing plumbing after the house is built: making a change that looks small can take a whole lot of effort with a whole lot of risk for collateral damage.

software automation Can software replace my job? It's a concern with roots going back centuries to the arrival of the first automated power looms in 18th-century England, continuing into more modern times with the large claw-like robots that build automobiles. Today it seems there are hundreds of websites making their living pushing clickbait headlines describing the perils of the coming Robopocalypse of software automation replacing human workers, and I often see those fears bubbling to the surface when working with clients. Fortunately, in my experience, those fears are often overblown, and I'm not alone in thinking so. Wired's James Surowieck agrees that we have nothing to fear.   The automation jitters usually start to come out during discovery. I talk with clients to clarify the business logic, workflow rules, or other automated features, and I'll use the term "robot" to describe the software we're building. After all, "if I can't tell the robot what to do, how will it know how what to do?" It's somewhere around here when we're asking somebody to explain their whole job function that somebody on the client's team will mutter, half-jokingly, "So I guess I better start looking for another job, huh?" It's not hard to understand where that thought is coming from. After all, if we can completely strip away the human layer and turn their job into a series of rote, mechanical steps, what role is left for them? I quickly try to assuage their fears.

It's easy to assume that a someone needing user support is not using the application correctly. What if there really is a bug? User support We've all seen the acronyms used by support techs: ID-10-T errors, PICNIC, PEBKAC, and so on. On the one hand, they're pretty mean-spirited (but kinda funny). On the other hand, support techs can legitimately be exasperated when rude, frustrated users scream at them to solve problems that aren't their fault. Yes, some support techs really do have to walk users through the most basic of operations like making sure the computer and monitor are plugged in and powered on. On the OTHER other hand, it is the job of support techs to bridge that knowledge gap. As consultants, we are often called upon to support our own or someone else's software. We have to be the opposite of that acronymic stereotype. Users aren't idiots; they're experts in something we are not proficient in and vice versa. Once in a while, we are on the receiving end of customer support, and these experiences can be real eye-openers. I remember one instance where we discovered an undocumented limitation of a mature third-party application.