Archive for December, 2010

You need a Text Editor

December 18th, 2010 No comments

It may not be obvious but you need a text editor once you  move beyond the most basic use of your Mac. You have three real choices. Learn a proper UNIX text editor like emacs or  vi, buy BBEdit or get TextWrangler for free. There’s another alternative I won’t mention because I’m a huge BBEDit fan and biased. Tough noogies. I’m not mentioning it.

I hate writing code. It’s not what I do. I can, if you force me, find and fix bugs in some language swhile enduring enormous pain and suffering but it’s utter misery for me. If I hate writing code, why am I telling you that you need a programmer’s text editor?

You can read the documentation on the above linked pages for all the uses somebody who is a programmer or system administrator will have for these tools and yeah, when I am a sys admin, I use those features. The official uses are myriad but you, like me, will likely find you have use for them in some measure for more uncommon purposes.

It will open essentially any file.

  • It’s a way to extract data from many old or mysterious files you’d imagine were of no use because you had no application that could natively open the file.
  • It’s a great way to find hidden data you might find useful in files you can open natively. Deleted changes from a file that wasn’t sanitized? Metadata about the creator of a file? You’d be surprised what lurks in some places and it can be useful to find out.
  • It will let you look at your own files before distribution so you can have increased confidence you’ve sanitized out any metadata you’d prefer not to share.

(Note: Don’t assume that because you can’t see metadata you might prefer not to have people see that it’s not there. It could be there in a binary format, hashed or even really encrypted. Just because you don’t have a means to decode it doesn’t mean somebody else can’t. The cleaning described above is just good practice but in no way a complete solution. It’s sometimes what we call “good enough”.)

They are also handy for more mundane tasks even less paranoid or curious people may need. These are a few things I can think of having needed to do at some point in the last month.

  • Need to do a multi-document search or search and replace? Say, for example, you have a pile of Word docs for an info packet. Sure, you’ll go back to the original word processor to make the changes to be sure you don’t break formatting but find where these mentions you need to update are, a fast multi-file search is a very handy thing.
  • Need to pull all the links off a page to do a manual link check or just save them all outside your browser’s bookmarking mechanism?
  • You have a backup of your WordPress blog and you want to take a quick look at a post offline.
  • You  use some other more WYSIWYG web authoring tool but you need to update a link from a machine you don’t have that tool installed on.(Never use a Word Processor for this. It will surely mangle your HTML)
  • You want to clean up the delimiter some program used for it’s export format. Came out as comma separated and you want tabs? Grab a BBEdit.

I’m sure many of you readers can think of other uses. Drop me an email or add a comment. Oh, and if you do drop me an email instead of a comment, tell me why? I get a huge pile of emailed comments and some of them make me make an edit or write a new post but I get very few proper comments here. Yes, I set it up so you need to register to make a comment which is, admittedly, a pain in the neck. It was a compromise to avoid the effort to do a whole bunch of mediation and spam filtering. Is it really that annoying to make an account?

Final note: If, like me, you don’t have either emacs or vi skills and aren’t overcome with an urge to acquire them, there is a nice alternative when you can’t install TexWrangler on a Mac you’re doing administration work on: nano.  It’s been mapped to the pico command by default in MacOS and, if you ever used pine for email, it will be familiar. To get it, open and type pico. The rest? You’re on your own but it’s not horrid to figure out and, unlike emacs, you won’t need an extra limb. Of course you can’t do what you can with emacs but then again, if you need emacs, that’s on your Mac too and you didn’t need this article.

Post to Twitter Post to Facebook

Categories: Tools Tags: ,

There be dragons in case studies in the I.T. press.

December 12th, 2010 No comments

I wish I could tell you all the horror stories. They’ve happened with some of the high budget projects I’ve done at every gig I’ve had. I’ll do my best to warn you without being able to actually show you all of the skeletons.

Somebody, usually somebody with more management experience than technical field experience will have a legitimate and very serious problem with how some workflow or business function is done at your company. They’ll meet somebody, read something and an email will arrive asking you to look into a new product or service that promises to solve their problem. The problem will be real and it will be important. Now, as a technology manager, you’re at a crossroads. How do you communicate your assessment of their proposed solution? Sorry, can’t help you. Too many variables. Is your boss ‘science minded’? Is she somebody you can have a real conversation with who will work alongside you to evaluate their idea? Damn, you’re a lucky devil. Is he a puffed up MBA-having-suit-wearing-testosterone-juiced-schmuck who got the job despite all reason? You’re hosed. The reality is, you’re almost surely waist deep in the vast expanse of gray in between. What I can tell you is, do some due diligence and don’t rely on IT industry press ‘case study’ articles and customer testimonials.

I first learned this lesson the hard way at my first real job managing a network and support for a medium sized business. I sold my boss on a service contract for CE Software’s QuickMail. We were already using QuickMail (served with damned near bulletproof reliability from an SE-30. I was pitched a long term contract by CE for a roadmap of upgrades. I was handed all sorts of documentation about how other customers were doing well in these arrangements and given prospective ROI analysis that painted a nice rosey picture for the future. I pitched my then boss with passion. I didn’t do enough homework. CE never shipped what they promised. The roadmap was vapor. My employer got screwed for a few grand. I felt terrible about it. My boss at the time, I think actually saw it coming and let it happen to give me some on the job training. He wouldn’t no matter how much I begged him to, let me point the company’s pit-bull lawyers at CE.  There were lots of lessons for me in this experience and some of those will be the topic of future posts. But the key lesson is, don’t believe what you read. Test, test, test.

What I can tell you is this. If you read an article in the I.T. press talking about how Enormocorp successfully deployed the proposed solution, it’s a lie. I mean it. If you read an article in “How to succeed in IT” magazine  featuring an interview with a CIO who just deployed a multimillion dollar CRM system and the quotes talk all about the amazing ROI, it’s a lie. It can’t be used as meaningful data in making your decision about whether your company needs the product. If the sales guy shows you this article? If he has a stack of five others like it? if his whole presentation is all about how deploying his solution will help make your small company able to be as successful as his Fortune 500 poster child clients? You are in serious trouble.

Now, did the CIO interviewed actually lie? Probably not. The article wasn’t long enough for enough truth. Here’s how it happens. How do I know? I was the guy you shouldn’t have relied on.

I was an avid user and advocate for Retrospect (A LAN backup package then made by a company called Dantz). I made a decent portion of my living for years implementing a series of successful deployments of Retrospect. Honestly, and I mean this, I saved companies I worked for literally millions deploying Retrospect for them. I enjoyed a great relationship with Dantz during this time and some of those people I knew back then at Dantz are, to this day, people I’d call friends. Retrospect was, at the time, a truly spectacular product.

My relationship with Dantz was so good, I got seeded with betas before they even admitted they were working on a new version. Back then, everything wasn’t in perpetual beta. I got surreal levels of support and I ate a lot of good meals on their dime. At the height of their success I was one of a half dozen or so consultants and I.T. managers asked to do a promotional interview for them. I can count on one hand with a spare finger or two, the number of companies I’ve ever trusted enough to say yes to that kind of request. I did the interview, I had a few laughs. The somewhat colorful  out-takes apparently made an internal reel shown to employees. I told the absolute truth. At the time, Retrospect essentially had a monopoly the automated backup business on MacOS and deserved to. I never had access to sales figures but I personally had well more than a thousand nodes in the  field  that I’d supported, deployed or spec’d at some very big name clients.

The day that tape was made, if you bought into Retrospect and had a clue, you’d have probably done very well for your users and bottom line. If, a year later, you saw that clip and invested in a large scale Retrospect deployment, you’d have done OK. If, two years later you had? Perhaps, not so much.

This was because the Mac, the only platform Retrospect really supported fully at the time, was in a major transition to OS X. This was not easy for a company like Dantz to cope with. Apple was in a certain amount of chaos. MacOS was being fundamentally changed from the ground up and Dantz was investing in more cross platform support. Ultimately, Dantz was sold to EMC. By then, while still a useful tool, things were far from the “This damned thing just works” truth I’d spoken on the tape. By then? What I’d said on tape became a lie. It wasn’t when I said it but it became one.

Also, the promotional case studies tape, because its purpose was to talk about Retrospect, no deeper discussion of backup strategies, archiving and good disaster planning was even discussed. If you relied on Retrospect as your entire solution you’d have been in deep trouble. I didn’t lie about how great Retrospect was but anyone who deployed Retrospect without a lot of other work and concurrent procedures could well have ended up screwed. Anyone who added up the number of seats they needed, added the most expensive Mac they could buy to the budge for a server and thought that actually represented the real budget to deploy was in deep trouble. If you heard me say “buying Retrospect will solve all your backup, archiving and disaster planning problems” then you heard a lie. The fact that didn’t say that, and would never have said that doesn’t help you feel any better about having trusted what you’d heard however much you heard was different from what I’d said on that promo tape.

So, that’s a best case where the well intentioned quotes become lies. Here’s another reality behind most of the quotes and short case study articles you read and I’m saying this because I have read them about projects I’ve worked on. The case studies are often written and most publicized before the projects are even finished. They’re written during the deployments and, as is usually the case, right when everyone working on the deployment is in a honeymoon with the vendor and the vendor is psyched to have a poster child client. The foot soldier employees probably aren’t working with the system on a day to day basis yet. The total costs of the training haven’t been accounted for yet. The costs of changes in workflow imposed by the tool haven’t been accounted for yet (and often never are). You’re being pitched the success of the John Hancock Tower in Boston right before the windows have started to pop out in the wind.

One particularly sordid example I need to be circumspect about was a client who spent, literally, millions on big iron to serve a website using what was, for about ten minutes, the high fashion CMS du jour. The CMS maker’s CEO was driving around in his ‘explosive dot com ere growth funded’ Ferrari talking about how well the CMS was doing in an emerging marketplace. The hardware vendor was crowing about the partnership. There was press about the client’s choice of and success with the CMS.

The truth, however, was that the website hosted on that CMS never worked properly. The developers who ultimately had to wrestle with it on a day to day basis were in agony.  It never produced increased revenue. It had downtime incidents that amounted to days in a year. The CMS vendor folded in a hail of internal acrimony. The language of the CMS fell into a level of deprecation that would make studying Cobol seem a good career move today. The hardware ended up being a hundredfold or more in excess of what was ever necessary with the price tag and sever room infrastructure costs to match. None of the experienced technical staff working for the client wanted it to happen. Everybody, including me, counseled against it. Press quotes, books, testimonials and buzzwords overcame seasoned judgement and millions were lost. The press about it? About this deployment? The case study quotes? All one hundred percent positive.

If you’re being pitched an enterprise product to revolutionize your business, don’t believe what you read. Insist on much deeper dialog with existing and current customers. Plan a staged process of test deployment and evaluation. Listen to your internal staff’s concerns. Don’t listen to lies even when they may well have been spoken with all sincerity.

Post to Twitter Post to Facebook

R&D-Ship Your Research

December 12th, 2010 Comments off

I’ve had a number of jobs over the years where R&D was in my portfolio as support staff, a participant and a manager and I’ve worked, as an I.T. tech, in pure research facilities. I’ve learned something. Ship your research.

I worked as the hands-on I.T. guy for a now defunct medical devices company. The job was great. I was there while they grew from about thirty people to close to two hundred over the course of about two years. Until late in my tenure there, all the R&D was done in specific support of their flagship product. Whether it was on the accounting ledger as R&D I couldn’t tell you but thousands of staff hours were spent on researching everything from materials science, manufacturing practices and, of course the formal clinical trials of their products. Virtually every dollar spent on this R&D was driven by a product goal. Everything tested and experimented with during my first year there was being tested for use in the product line they actually intended to ship. Nobody was on the clock saying “I wonder if.”. If somebody had an idea, If it wasn’t vetted as having a potential commercial future, it didn’t get done. There was no ‘pure R&D’. That didn’t mean some ideas didn’t get very far along before they died. I remember every man and woman in the company being brought into a room to feel plastic breasts. We went in, we were asked “does this feel real”. A few weeks later we were asked “Can you find a lump?”. The goal was a training simulator for breast examination. As I recall, and I could be wrong, the conclusion they came to was that the stimulants of breast tissue, skin and lumps couldn’t be made meaningfully enough realistic to make it safe to teach to ignore what to feel as case to for concern and what to feel as normal variation. The project was summarily killed and the staff back on in process projects without any kind of merciful pause or mourning period. It was a dead end quickly.

I worked for another company that was ultimately sold to a very large company you’ve surely heard of. I got supremely lucky in my brief tenure there. I arrived at the worst possible time to actually achieve any of what I hoped to when first took the job but the President and CEO were extremely honorable and generous with me despite the chaos that began a week after I arrived. Frankly, I seriously lucked out. It was immediately scary within mere days of my hire but that panic ultimately evolved into the sale to ‘unnamed huge company’ and most of the engineering team went on to jobs there and do major work, on the other side of the country. That company, the one sold, began life as a firm doing very academic R&D funded in large part by SBIR grants doing work for NASA. Things even now not yet, as far as I know, deployed by NASA. The things they built, the prototypes done as R&D were shockingly cool things. Things I still, more than a decade later, haven’t seen make it into mainstream products. The brilliance in what they built is impossible to articulate. These people, from the founder on down were shockingly smart. They built controllers for telepresence and simulations that included touch feedback. Now, we’ve all felt a gun in a console game that jumps in your hand when fired. A steering wheel that rumbles when the virtual car runs over a bumpy patch on the pixel track. Imagine touch feedback so nuanced, so elegantly implemented that you could feel the shape of a virtual space you couldn’t see while walking through it with a joystick. Imagine feedback so nuanced you could draw the shape of a virtual maze based only on what you felt from the joystick. Imagine touch feedback so good that if you used it on a steering wheel in a game, it made you able to drive the car closer to its limits and complete laps faster. The steering of my real car is ‘drive by wire’ more than fifteen years later and it gives me less useful feedback than those prototypes. The R&D that built the prototypes was R&D with a purpose but it wasn’t R&D that was ever intended to end up in anything like the test form in a final product. They weren’t rough drafts, they were proofs of concept to learn from. None of that work was ultimately visible as more than a faint glimmer in the final shipping products. No fault on anyone there, the costs involved and target market of the final products not only precluded it but actually might have made the product inferior.

Before both and after both of these jobs, I’ve been employed as and a consultant to pure academic research facilities mostly in biotech. Academic research is, and should be, a completely different ball game. It’s not technology R&D, it’s science. There are critical differences there. The purpose of science is discovery. Pure, simple, discovery. Sure, maybe it will lead to a new medication, a new procedure or a business opportunity but that isn’t, and can’t be, the purpose. The purpose is “Let’s build a test to see how this works”. You don’t, for example, send the Voyager space probes to invent a product. You do it because we, as a species, need to learn. Of course, there will usually be technology innovations created in support of the research that could lead to business opportunity but the purpose of the work is pure learning. Cancer research may lead to cancer cures. Pure academic metabolic research might also. You have to invest in basic research on cellular metabolism whether or not you’re studying cancer. The current climate of public derision in the press for research that seems to have no probable useful purpose is bad for society. Research, pure research done with scientific rigor is vital for its own sake. Science is enormously important. Our society is investing less and less in true science and that’s deeply disturbing. It is important to remember though that R&D is not science even if we seek to apply scientific rigor.

Finally, I’ve worked on  a lot of new media jobs. All these experiences above taught me this. When you’re doing R&D in a commercial tech company? Ship your research. I don’t mean literally take an idea all the way to a product you sell. I mean treat it like everything will be or will be used for shipping products.

If you want to explore a technical idea, an innovation, invest in it when you think can actually use it. Don’t expend your core resources just fiddling around. Find a business goal you think your idea can support and find a way to make the project fund the research or the research fund another business goal. So, for example, let’s say you want to experiment with a new CMS, find a project that needs the functionality you want to explore. Do structured tests to see if what you want to be true stands a decent chance of being true. Set break points to check your thinking and set about actually doing work with the experimental notion with the idea you plan to ship it. Don’t fund the research out of R&D, fund it out of an actual project. Do the research with the same level of rigor you’d bring to production methods you already know and use. You will, I hope, fail miserably regularly. Failure is the cornerstone of innovation. You have to be prepared to throw an idea away that’s clearly not going to work.

The thing is though, if you don’t treat your R&D with the same level of rigor you would if it was sure to actually ship, you’ll learn nothing. You’ll never stress test the idea. If it’s a new software tool, you’ll never test the vendors support services. If it’s a new version of a tool you already use, you’ll never put it through the mundane day to day processes you’ll have to when you’re actually doing production work.

The worst mistakes, the most disastrous  dead ends, the most massive cost over-runs and delays were almost always something you could trace back to a decision that went like this: “We’ve spent a few weeks looking at this tool and reading up and we want to invest in this tool.” Investment in a tool is sometimes just training and time. Sometimes it’s millions on expensive hardware. All of these messes arose from somebody thinking the technology itself could do magic. People do magic, technology doesn’t. Only applying the same level of self criticism and doubt to your ‘experiments’ as your customers will to your products can you make efficient use of your research.

A concrete example should make this clear:  If you make television shows and you want to try a new editing system (NLE), deploy one and use it. Now, testing a new new NLE may not seem like R&D but it is. It’s what needs to be done to stay at the cutting edge in the video production business. First, use it to produce an internal project. A real project with stakeholders and somebody other than you setting expectations for turnaround time and quality; an internal presentation reel for example. Remember though, don’t cut something that nobody cares about. Cut something that somebody outside the testing group cares about. Something underfunded but low stakes. Use the R&D budget to make a skilled editor available to this project. Use the R&D budget to rent this much desired new system for the important internal project that couldn’t otherwise afford it. Pick something gnarly. Something with footage from disparate sources. Something that relies on your motion graphics group to make assets for. Pick something with a picky stakeholder who will make you make a pile of annoying last minute changes. In the middle of the project? Break the NLE. No, I don’t mean spill coffee into it, but I do mean break it. Install something you shouldn’t. Disconnect the media drive in the middle of a render. Delete some obscure application file and call for support. See how it will be when there’s an air date on the line. If your internal project survives all this. If your experienced editor comfortably adapts to the tool. If they like the tool. You’ve given your senior staff a chance to play with a new tool. They get professional and personal development. Your ‘no paying client’ internal project that was important enough to fund got done with the money set aside for R&D. Your test of the new tool stress tested it.

Next step. Use the new NLE on an actual project. Not one for a client but one that’s complete. One you’ve already shipped that you’re proud of. Assign a junior editor and producer to re-make something that’s already been done from the carefully archived materials for a finished project. Then you’ll test your NLE with a real volume of footage. The previous finished product is the benchmark for the re-make. Everything from lower thirds, to effects to closed captioning gets put through the workflow with the new NLE.

If the new NLE lives through this test, you’ve really stress tested it. You’ve reduced your business risk in deciding to deploy it on paying projects and you’ve done these tests with enough different people involved you can make your choices based on feedback from the people, your people, that will need to rely on the tool. You didn’t just read an article and say “it’s the latest thing we have to use it”.

You’ll have tested your archiving compliance. You’ll have given your senior staff a chance to participate in a strategic choice. You’ll have given your junior staff to learn new things and get their hands on playing with a flagship project.. They’ll learn from how their more experienced colleagues work. You’ll have a low risk letting these junior staff try things and see how they perform.

You’ll get to see how the NLE that survived the stresses of making a five minute internal demo reel. If the new NLE survives that test? Then you deploy in a relatively low stakes project in production. It’s R&D research and development. You researched the viability of the tool and you developed the internal resources to deploy it. Even if it turns out to be badly supported overpriced junk you’d never buy in any volume, you’ve spent your R&D money well.

R&D in I.T. and New Media Production is about testing new tools, new workflows, new ways of capturing, organizing and presenting information. Your time and money should be spent moving to scenarios where you’re actually testing the ideas in real-world scenarios while managing risk. Maybe it’s a new visual metaphor. Prototype it and get it in front of real users not your staff and do it in a structured and objective way. Go in hoping it will crash and burn as much as you’re hoping it will be a breakthrough. If you’re not, very quickly, imposing discipline on your process you’re wasting money and putting your business at risk.

Post to Twitter Post to Facebook

Categories: Inspiration, Media, Tools Tags: