forge

The Tivo Out of Box Experience is REALLY bad

It is amazing to me just how bad of an out-of-the-box experience that you can have with Tivo.  For all of the good things that the product does, it’s like there’s a completely different company managing their out-of-box experience.

I wanted to summarize for folks the situation that I ran into recently when I purchased a Tivo unit with DVD recorder for the church I attend.  I purchased it to record and store content from a specialized satellite subscription that the church purchased.

To start, you must use the phone line for initial connectivity and there is still no network connection on the unit I purchased.  You can add a USB-based network card, however, it’s a separate accessory that you have to buy.  Not a big deal in the grand scheme of things, however, it can make logistics difficult as it did for me.  To get the unit started you must complete the setup calls (not setup call as seems to be the common parlance.)

So I plugged the unit into a line that I thought was an analog phone line — it turned out to be a digital phone line — and the modem burned out… when the replacement unit arrived I plugged it into the line for the fax machine (which I new was analog).  It completed it’s first call and then asked me to setup the A/V sources.  I go back to try to tell it that I want to specify my sources, since specialized satellite wasn’t one of my options.  It forces me to make the 10 minute setup call again because I transitioned back before the call to change the sources.  I get to the same screen and eventually turn the unit off and take it back to the room where the satellite is connected.  When I plug it back in it forces me to go back through the setup again — including the phone call … which I can’t make because the phone is in another room.  (Are we beginning to see the insanity?)

So I decide I’ll bring it home where I have phone and video together and then move it back to the church.  That’s great.  I start the process all over and get through the first call and the setup relatively quickly.  (I was doing other things at the same time.)  Then it goes to make a second call.  After the third failed attempt I replaced the relatively long phone cord with a short cord.  It’s still not working.  Each attempt takes five minutes or more because it doesn’t restart the download and in fact it does a cleanup activity prior to starting.  Needless to say it’s a painful experience.  I have Vonage for one of my phone lines, the one I was using.  So I eventually tried the other line and it worked … and at the end it says that the unit will be working for between four and eight hours and I shouldn’t unplug the system until it’s done.  It doesn’t indicate how I will know if the unit is done, nor does it indicate if there’s a safe way to power down the system that won’t cause any issue.

What irks me most about this whole situation is that less than a dollar could have put a flow chart of setup activities in the box.  Something that would have shown me the steps I’d need a phone line for, the overall process, and how to deal with common issues — however, that level of thought wasn’t put into the out of box experience — in a company that spends so much time working on user interfaces, ascetics, and other “user touch“ aspects.  It’s unfathomable that they wouldn’t put more thought into the out of box experience.

I’m now sitting with a Tivo unit on my desk that needs to go back to the church.  I’ve invested hours getting the unit to work for something that frankly should have just powered on, started up and let me use it as a glorified VCR without any of the issues I ran into.

By contrast, I’ve had a replay TV unit for three years now.  The out of the box experience was easy. I had the option of using either a phone or the network.  As I remember it, there was a basic set of instructions for what was going to happen and what I needed to do.  It was an extremely installation…

Now I need to see if I can figure out how to get the unit to tape from the satellite feed back at the church or if I’m not done dealing with the setup process. At least I can connect it to the network, if I can figure that out…

The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP

Book Review-The Rational Unified Process Made Easy: A Practioner’s guide to the RUP

It’s very in vogue to describe your software development process as RUP.  Describing the current methodology as agile (XP, Crystal, Scrum, etc.) evokes too many questions, but describing the methodology as Rational Unified Process, more frequently RUP, leads to fewer questions but puts you ahead of those who are still running a waterfall process.  However, in many cases RUP isn’t really the methodology being used, it’s simply renaming some of the processes and artifacts that were done for waterfall with new names.

The beauty of the book The Rational Unified Process made Easy: A Practitioner’s Guide to the RUP is that focuses not on enumerating the artifacts that one might use with RUP but rather focuses on the core concepts, fundamental precepts, and spirit of RUP.  In this way it intentionally steers the reader away from the natural tendency to try to implement every artifact, to create the highest ceremony process possible.  It provides a balanced view on how to utilize RUP to run effective, successful software development projects.

It also contains a role-by-role review of RUP.  This provides a view of the process from each role’s perspective.  The benefit of this is to condense the amount of training that must be done to get everyone working on the same page.  While they can not be considered a direct replacement for training, the chapters are a good start to helping the team member understand what RUP is all about.

Even in a world enamored with agile, RUP still has it’s place.  It’s proven for larger projects, and provides a path to an iterative model — essential to every form of agile development.  If you’re trying to get to agile RUP is a good stopping point along the way — and the book The Rational Unified Process Made Easy is a good way to understand how to do RUP.

forge

Good Quality Assurance Information

I’m preparing for a presentation to the Indianapolis Quality Assurance Association on February 16th titled “The Impact of Coding Standards and Reviews on Quality.”  I stumbled across a link that is titled Quality Assurance, but is really a collection of really good development ideas, some of which are quality ideas, but many are ideas for better development.  You can find the link here.

Good ideas like defensive programming, exception management, and others are woven throughout this document — it’s an interesting read.

forge

Article: Effective Code Reviews without the Pain

Code reviews in most organizations are a painful experience for everyone involved. The developer often feels like it’s a bashing session designed to beat out their will. The development leads are often confused as to what is important to point out and what isn’t. And other developers that may be involved often use this as a chance to show how much better they can be by pointing out possible issues in someone else’s code.

Code reviews, however, don’t have to be painful.

Remembering the Purpose

Code reviews have two purposes. Their first purpose is to make sure that the code that is being produced has sufficient quality to be released. In other words, it’s the acid test for whether the code should be promoted to the next step in the process. Code reviews are very effective at finding errors of all types, including those caused by poor structure, those that don’t match business process, and also those simple omissions. That’s why they are an effective litmus test for the quality of the code.

The second purpose is as a teaching tool to help developers learn when and how to apply techniques to improve code quality, consistency, and maintainability. Through thoughtfully evaluating code on a recurring basis, developers have the opportunity to learn different and potentially better ways of coding.

Read more…

forge

Rant: Book Development Editors are a dying breed

I used to do a lot of development editing for books.  It was fun work.  You were able to see the impact on the books you were working with.  You could see author’s writing getting better as they started to get used to your comments.  They would quit taking short cuts.  They would begin to view the material from the reader’s point of view.

The job of the development editor in the book process is to “develop” the material.  In other words, the development editor is supposed to make the material better.  Development editors don’t do this by adjusting the placement of the commas or the number of capatilized letters (that’s the copy editor’s role.)  Instead, the development editor looked at the tone, overall flow, depth, and other broader issues.  They focused the author’s attention on these issues so that they could be improved upon.

What I’ve realized from the reading that I’ve been doing lately is that the development editors aren’t doing this today.  It’s likely because they’re too busy with other projects but still the abscense of this assistance for the author is painfully missing from many technical books today.

The book industry is right to be scared of the Internet and the way that we consume information these days, however, they’re not doing themselves any favors by shortcutting the development process in favor of books that are quicker to market.

I read a lot of blogs, articles, and shorter content on the Internet.  However, when I really need to have a thorough understanding of a topic, or I need to make sure that the information is right, I go to a book.  I use them as authoritative voices — however, this is challenging for me when the books have no more thought or organization to them than a typical one of my blog posts.

I wonder if the technical book publishing community will totally collapse before they learn what made Wrox what it was. Ok, before they went bankrupt.  The point is, however, that the brand of Wrox was powerful.  Having the opportunity to work with them (as a technical editor), I can tell you that they crafted their books.  The development editor was very involved.  They had the material run through two technical editors.  Everything was designed to get a quality product — at the center of that effort was the development editor who was managing all of the support that they were providing to the author.

Of course, the days where you could expect that a book won’t wander — that it will follow a clear, intelligible outline are long gone … Some days, I wish I could go back.

Software that Sells: A Practical Guide to Developing and Marketing Your Software Project

Book Review-Software that Sells: A Practical Guide to Developing and Marketing Your Software Project

Do you know why you don’t see a lot of negative reviews of anything in magazines?  The answer is simple.  Why print something that is negative when you can just as easily print something positive?  Well, the beauty of a blog is that I can post something negative if the item deserves it.  This is one of those cases.

I just finished reading Software That Sells: A Practical Guide to Developing and Marketing Your Software Project.  Actually, there were several sections that I couldn’t force myself to read.

The information contained in the book is trivial, obvious, and sufficiently non-specific so as to be non-actionable.  In other words, this is stuff that nearly everyone knows.  You could buy someone in your area a drink at the local tavern or pub and get a more coherent delivery of useful information.

While I do realize that there are some folks who are very early in their careers who might be able to find value in the broad coverage of topics, most people will find the coverage too trivial.  What is worse, in my opinion, is that the author doesn’t provide the reader good references to go find more information.  There are chapters on marketing and sales, but no references to other books that cover these topics in detail.

So, if you’re trying to figure out how to start a Micro-ISV (small software product company) you may want to keep looking for a good book.  (Micro-ISV by Bob Walsh is on my reading list still.  I’ll let everyone know what I think of it.)

dashboard

Fundamentals of Performance Testing

I’m in the process of writing an article for TechRepublic.com on the declining importance of performance testing.  Without getting into the articles primary arguments, I came to a realization that I felt compelled to share.

Most IT professionals have no idea how to approach performance testing.

I mean that both from the sense of they couldn’t do the testing if the needed to and also from the perspective that they don’t truly understand how it works.  The article for TechRepublic.com is, as most of my articles are, born out of experience.  I’ve noticed that way too many organizations get hung up on performance.  They avoid items which have been identified as non-performant but which make the development process much easier and therefore it costs less.

So in the interest of educating folks, here is a high level summary of what you should know about performance testing, the details will be in the article …

  • Performance Testing – Performance testing is really a set of related evaluations of the system including: responsiveness, throughput, and scalability.
  • Responsiveness – Responsiveness is how quickly the system can complete an individual transaction.  As the throughput of the application goes up responsiveness typically goes down.
  • Throughput – Throughput is the rate at which transactions can be completed.  Typically maximum throughput is the number that organizations are trying to find.
  • Scalability – Scalability is the amount to which various changes to the environment can impact the maximum throughput and to a lesser extent improve responsiveness.  Different changes can result in radically different effects on throughput expecially when the scalability is directly related to a bottleneck.
  • Bottleneck – A bottleneck is a performance constraint in the system which prevents the throughput from increasing.  Typical candidates for bottlenecks are processor performance, available memory, disk performance, and network performance.

I hope this helps.

forge

Article: Choosing Between a User Control or a Web Part for SharePoint

I generally recommend that users don’t write Web Parts unless they have to. That confuses a lot of people since most people believe that you have to write Web Parts if you want to do work with SharePoint. This is only partially true.

SharePoint will only display Web Parts on a page. However, there are publicly available shims that allow you to write user controls and have them be displayed as a Web Part. From SharePoint’s point of view, the shim is a Web Part. From the point of view of the user control, the shim is simply a control in .NET that is including the user control.

http://www.intranetjournal.com/articles/200601/ij_01_20_06a.html [Website no longer available]

The Tipping Point: How Little Things Can Make a Big Difference

Book Review-The Tipping Point: How Little Things Can Make a Big Difference

If you’ve been reading this blog then you know that I’ve been doing a lot of reading of my own lately, mainly associated with some professional development in the area of reconnecting to basic software development fundamentals that I’m already aware of and some new things as I try to find some new ideas in the various forms of the agile development movement that I can use or try.

The latest book is radically different.  It’s one that was casually mentioned to me by a colleague, Jeff Juday, who was recently awarded Microsoft MVP status.  He mentioned how he thought the program related to the book he had just read, The Tipping Point.

This piqued my interest initially because I’m always curious about how the market works and Jeff promised the book would have some insight.  (He was right.)  Having written (or written part of) 16 books, I know how random sales can be from one title to another.  In fact, when my friends and colleagues approach me about writing a book and ask me if their idea is a good idea, I usually respond with I have no idea.  The market seems to work in mysterious ways.

The Tipping Point is a book about epidemics.  Not so much the negative things as we associate with the word epidemics but rather about things that have a radical growth cycle.

At some point in the book, I wanted to share a passage with everyone I knew.  Some of my mentors, the pastoral staff at the church I attend, my mother, several of my friends, and some of the folks I know at the MVP program at Microsoft.  The truth is that when I finish this blog post many of them will be receiving a link via email to check it out – excluding those I know read my blog regularly and so they’ll see it anyway.

I found the book enthralling as I examined some of the market reactions I had seen.  The birth of the Internet (really the adolescence of the Internet), the growth of cellular phones (which the book discusses), and I even thought about it in terms of SharePoint Portal Server.  (For the record, I would have written this blog post even without a SharePoint tie-in.)

I remember working with the 2001 version of SharePoint Portal Server.  When I’d talk with my peers most of them would be asking me – “Share What?”  There weren’t many people that knew what it was.  Today, when I talk about SharePoint to people I meet – even outside of the industry – I get a surprisingly high awareness rate.  Most don’t know what it does exactly but they know that people think it’s something to watch.  (As a sidebar, most people who do SharePoint work don’t know exactly what it does.)

The interesting thing is looking at this pattern – and others – and evaluating why SharePoint is such a pervasive word in the IT industry and in the minds of small business owners.  It certainly can’t be attributed to the stellar marketing that Microsoft has done for the product.  (Sorry guys.)

Quietly you’ll get some of the marketing folks in the information worker group to admit that there’s a lot of confusion about SharePoint and few places to find good answers.  I’ve had clients pay for us to develop documents that they can use to internally explain the solution – because it’s simply too hard to do without clear documents on what it does and doesn’t do.

SharePoint isn’t successful because of a greater number of people running Microsoft Office.  SharePoint’s popularity can’t be explained by a renewed interest in IT.  It’s an absolute mystery to me as to why it’s become so popular.  (Here’s a challenge – tell me via email why you think it is so popular.  I’d love to hear your perspective.)

The Tipping Point didn’t explain why SharePoint has become so popular but it did give me the clues to look for to identify what happened.  I don’t have the answers but I do at least know some of the questions to ask.  In that way, I think it will be invaluable in the way it allows me to see things more clearly.

The analogy that I’ve come up with to explain it is that it’s like someone with imperfect vision – like myself – putting on glasses for the first time.  It doesn’t make me see or allow me to see for the first time but it does bring more clarity to what I’ve been seeing all along.  The unfortunate thing is that it has also exposed me to how much I still don’t see.

There are some psychological tenants that most people subscribe to – including me.  That I know believe are false.  I’m questioning how much about the way people behave is about their character and how much is about their circumstances.  (In an interesting turn of events, the environment swapping movie Trading Places was on TV last night.)

If you’re the least bit curious about how trends get started and would like to get a little bit better picture of them I highly recommend reading The Tipping Point.

forge

Recognition vs. Recall

Where did I put that again?

One of the things that’s been fairly constant in my life over the last few weeks — that rediscovery stuff is hard, particularly when you try to do it too quickly.  It’s caused me to recognize that there’s information I’ve seen before but I couldn’t recall it on command, nor can I even remember where I saw it again.

It reminded me of some of the instructional design research I did several years ago while I was doing a lot of development editing for books.  I ran across Bloom’s Taxonomy of Educational Objectives, while I can’t say that I agree with every bit of the classification or the revision of the work.  However, it’s interesting because it causes you to think about how we teach and learn in a different way than we most folks think about it.

What caused me to think about it was the difference between recognition and recall.  These are at the bottom most levels of the taxonomy.  The most basic level is recognition.  That means that if someone asked you what it was you couldn’t tell them but if they say it to you — you will recognize that you heard it before.  Taking from my daily life…  My wife asks me to pickup paper plates from the grocery store.  I walk into the store and can’t remember what it was that my wife asked me for.  (I lacked recall.)  However, my friend, who co-manages the store walks up to me and starts offering ideas on what it might be: bread, milk, cheese, etc.  When he hits paper plates I immediately recognize that it what I’m there for.

The trick, for me, is to figure out how to get more of the stuff I read and take in into the recall category and less in the recognition category.  I could be struggling for higher levels, levels that allow me to do things with the information but for now, I’d be happy to hit recall all the time.

Excuse me while I go look for my car keys…

If you’re interested in learning more about how we educate ourselves and others, it’s an interesting read.