I have decided I have a new term that just bugs me — “knowledge transfer”.  For whatever reason, people seem to think that information can just be knowledge transfered around from one person to another and that all will be OK.

It is a frequent phenomenon at work.  I had conversations today about sending a person out to a location to gain “knowledge transfer” of the system that is being developed.  Only for that person to then come back and “knowledge transfer” to people here.  It makes it sound like some kind of Borg download or Vulcan mind-meld is going to happen and then all will be fine.

Hate to say it… but it is never fine.  Didn’t you ever play that party game where something is whispered around a circle and by the time it gets back the saying has completely changed?  Same concept… so naturally same result.

Ack!  Rant complete.

Hey hey!  A new look for the blog site!  (If it looks funny for you, refresh the page…)

I’ve been working on this for a few weeks off and on.  It’s been a good learning experience.  I’ve gotten a lot better with my CSS skills and I’ve even learned some PHP code.  All to bring a more “alive” experience.  The quotes at the top of the blog are randomly chosen from a database of quotes that I will maintain (so they’re only quotes that I like!)  And the iPod item at the side will refresh with a new selection from my iTunes database.  Pretty cool.  And finally, the picture in the upper left corner will also change from a selection of a few of them.

Hopefully it is all working.  I know that the Archives option at the top is not working yet.  I will get to it soon.  But I’ve tested everything else in both Firefox and Internet Explorer and it seems to be OK.  But if you see otherwise, please comment and let me know.

“If it’s complicated, then it’s wrong” — Me!

I have said the above phrase to a lot of people in my quest for writing good software. Sometimes people get it. Many times people just smile and say “OK”, but they don’t really understand. The “OK” repsonse happened just the other day and I decided to attempt to explain my reasoning.

The main concept in my mind is the following: There are many business processes that are complicated (that’s a different story - we’re talking about software for now). A complex business process does not mean that the supporting software needs to be complicated as well. I constantly find that the complexities of a business process get duplicated in the design of the software. And the typical verbal defense for the complicated software? Well… the business process is complicated.

Hogwash. Don’t let a business process dictate the design of your software. Abstract things out. Look for patterns and apply them. Encapsulate things that are complicated with simplified interfaces/wrappers. Document and unit test your code along the way. If it’s difficult to document or unit test, then maybe it’s too complicated to begin with. If the software is difficult to follow, that’s the designer/developer’s fault - not the business process. Please don’t use a complicated business process as a justification for your complicated spaghetti code.

The flip-side can also be true. If the software is getting difficult because of the business process, then maybe the process should change. But that is a different topic, and not one that a developer has control over. So take control of what you can (the code) and at least make things better for yourself.

If you have been doing software development work for any period of time you have probably experienced a project that eventually dies, for whatever reason. This week, it happened to me. A project that has been 2 years in the process has been dumped by the customer. They’re “going in a different direction”.

It’s amazing to me how a company can allow a project to get into this kind of state. Thousands of man hours and hundreds of thousands of dollars dumped into a project. The software had even been delivered and is functioning in a pilot. But alas, I guess it was not meant to be.

In a way, it becomes a relief because the project had been floundering for a few months. But mostly it is just a disappointment. A lot of good work was done by many people. And while it was certainly a good project and a lot of lessons learned, it still hurts to see it die.

Went to Target last night and saw that they have H&R Block’s Tax Cut software on a flash drive for distribution. It cost slightly more than the CD version (about $5 more), but then it comes on a 256meg USB drive - which you could then use for other things.

It was only a matter of time, and it does intrigue me. I didn’t buy it (I’m a TurboTax guy myself), but I am curious as to how it works. Does it run the program from the USB drive? Does it automatically save your tax files to the USB drive? Could I start my taxes on my machine at home, then unplug the drive and plug it into my laptop and resume — without any real effort (that’s the key)?

USB drives are getting cheap enough that it could be a viable distribution mechanism for software. It’s intriguing from the usability standpoint. For example, if you could have your finance program (Money, Quicken, whatever) on it, with all of your files so that you could just plug it into any machine and update records. There are certainly privacy and security issues to worry about, but I like the concept.

It could even work for a point-of-sale system. Cool! Imagine… point of sale on a USB drive — just plug it into a PC with an internet connection and start ringing sales. Excellent…

I read a posting in the Agile Usability Discussion Group regarding Netflix and a fast iteration development cycle. There was a link to an article on uie.com regarding the subject. If you’ve never seen the Netflix website (or used Netflix, for that matter) — first, shame on you. You should use Netflix because it is fantastic and it will help my stock holdings. The Netflix website is consistently voted as the best website available, and I agree. The article details how their development team uses fast iterations to get things done — did you know that they release production software every two weeks?

“We make a lot of this stuff up as we go along, I’m serious. We don’t assume anything works and we don’t like to make predictions without real-world tests. Predictions color our thinking. So, we continually make this up as we go along, keeping what works and throwing away what doesn’t. We’ve found that about 90% of it doesn’t work.” — Netflix Lead Designer

I love this philosophy. I’ve always been a fan of quick iterations, with releaseable software as a result of each iteration. That’s the key. But I have to admit, it’s a lot easier said than done.

Fast iterations can be used with web development fairly easily. In fact, with anything where there is “one” customer, it can work — a public website is exactly that.

But we have constant problems trying to get it to work with software that is bundled and distributed to customers. It is more difficult, but certainly not impossible. In those cases, its important to have a fake customer. Iterations should still occur quickly, and software should be in a releaseable state at the end of an iteration. It isn’t necessarily released to your customer, but instead QA people can be the customer.

It’s not as good as Netflix’s iterations, but it is certainly better than nothing. Software design is always a fluid process. As long as you can get some kind of feedback quickly, and then adapt accordingly, you are much better off.

Went to the voting booths yesterday - or should I say the voting terminals. For the most part, I think Utah’s new computer voting systems worked pretty well. I know that there were a number of cases of systems not being available and some inconveniences, but I’m looking at it from a pure techno/geek/software perspective.

For me, it was quite simple to use. They gave me the card, I inserted it, touched the screen a bunch of times, and then finished. Simple and straightforward. From a software design perspective, it was quite intuitive. But I admit, I may be biased. I deal with computers day in and day out, so for me to say it was “easy to use” probably isn’t very telling. But in observing the other people in front of me, it seemed that it was going well.

So the new system gets the thumbs up from me. Welcome to twenty-first century democracy! Now as long as there aren’t any bugs in the number counting, like some Hollywood productions would like to think…

The following is a post I made a number of months ago on the old blog. I thought I’d repost it here. Lately it’s been on my mind again.

I consider myself a refactoring junkie. Anytime I look through any amount of code I am always watching for code duplication, unnecessary code, complicated methods, bad variable names, etc. There is no real method to how I go about it. I usually start somewhere and see what I can find. It’s the old sweater syndrome — pull one thread and see what unravels.

However, in order to be so cavalier in refactoring, there has to be something there to back me up. The most frequent back up is the compiler. I can refactor left and right, changing things that will cause compiler problems. Then I just move through the compilation errors and take care of them. But the best insurance policy are unit tests. Of course, that assumes they are present…

Unfortunately, the need to get my refactoring fix doesn’t always go over so well with other people. “You want to do that now?”, or “yes, it needs to be done, but we have a deadline to meet” are frequent reactions. Most of the time I think it is just fear. And even when there are unit tests, there’s still fear.

So my advice to everyone:

• Refactoring is good. If you’re not skilled at it, there are many resources. I’d suggest Martin Fowler’s Refactoring, or Kent Beck’s Test Driven Development as good resources.
• Use the IDE. Eclipse and IntelliJ are both very good with refactoring code and showing where code can be fixed.
• Two minds are better than one — pair programming on refactoring is often very beneficial.
• Bottom line… try it! That’s what CVS is for! Change the code and try it out. You can always revert to the old stuff.

Over the last 4-6 weeks I have been going back and forth with credit companies in attempts to get several retailers up and running with a credit processing implementation. I have come to the conclusion that it is a wonder anyone can process a credit card. And no wonder merchants have to pay a transaction fee, the cost of all this complication has to be accounted for somewhere — may as well make the merchant pay for it! Sheesh…

There are too many moving parts. And while many moving parts doesn’t necessarily mean something is complicated, it does make the possibility higher. And in this case, too high. POS software, payment processors, banks, oh my!

Why do people insist on making things more complicated than they need to be? For heavens sake… messages are sent back and forth in bytes… bytes! One character is off and it screws up everything. Everything has to be configured exactly correctly, and there are hundreds of ways to screw it up.

Everyone keeps saying “it’s just the nature of the beast”. I don’t accept that as an excuse for software that I have control over — if it’s complicated then it’s wrong. But I guess have to live with the reality. Arghhhh…

I have realized lately that my job as Product Manager actually consists of constantly asking questions (often naive questions) to get to the bottom of why things work the way they do, or why a design is heading in a particular direction. I didn’t realize there was a term for this kind of behavior, but I’ve been informed that there is — it’s Socratic. As in the philosopher Socrates.

“The only true wisdom consists of knowing you know nothing” - Bill philosophizing with Socrates

I end up doing this all the time. Asking questions to answer my question. It’s probably annoying sometimes, but it certainly works. As people explain designs to me I ask questions. But often times I’m just asking questions to help steer things in a direction that I think they need to go. Rather than just stating that something should be a certain way, I’ll ask questions to get the other person to realize that it should be a certain way.