BKeeney Briefs

The number of bug reporting systems REAL Software has implemented in my time using REALbasic has been astounding.  Of course, some of the changes revolved around the emergence of the internet, but still, I’m amused at the iterations.

There was REALbugs (?) that was a standalone app that I never really used because I was a newbie. It memory serves, it was very much a Mac OS 9-type application.  As to how well it worked – I couldn’t tell you.

Then there was the feedback web site that allowed you to sign on to a bug to ‘vote’ for it.  It was nice, but people would literally sign on to EVERYTHING which defeated the purpose of the voting system to begin with.

Then RS switched to FogBugz and abandoned all of the old feedback items.  Supposedly, it would make life easier on them and they’d be able to fix bugs easier and faster.  Unfortunately, it made bug reporters life much harder since we couldn’t search the database.  RS was inundated with duplicate items and it was hard to tell the good reports from the bad.

So, now, in the current iteration we’ve come full circle and we’re back to an application called Feedback and is part of the download package.  It’s better in most respects to the previous system other than that it’s an application which just seems….odd in today’s internet world.  But I understand why they did it and for the most part it works.

It’s user interface forces you to search for an existing bug before you can add a new one (that’s good!).  You can see the newest cases (handy if you’re evaluating a new version of REAL Studio), My Cases, Participating In, and My Favorites.

You can add cases to your favorites list by clicking the star at the bottom of the cases listbox.  But a not so well documented feature is the Priority List.

The Priority List allows us to prioritize our bug fixes and feature requests.  This supposedly gives RS some feedback into what we want fixed or implemented sooner rather than later.  It’s also weighted in favor of the Professional and Enterprise users (we can argue whether that’s a good or bad thing in another post).  There is an algorithm to it but when I had my conversation with an RS employee I didn’t take notes so I might be off on the actual numbers.

A Personal license gets a weight of 1.  A professional user vote gets a weight of 10 and Enterprise has a weight of 20.  So Enterprise users are 20 times more powerful than Personal licenses.  That doesn’t strike me as too off base since a Personal license is $99 and the Enterprise is $995 (again we can argue the logic of the weighting another time).

Perhaps the smartest thing they did with the priority system is that you only get five votes and if my memory serves (forgive me, this is the day I got the flu), I believe a #1 rank gets 5 points and the last vote only gets 1.  So you have to be smart with your priority list and to edit it, go to My Cases and click the Edit Priorities button at the bottom of the list.  A separate list of all the cases you have some interest in are presented and you drag reorder the cases as you see fit but only the top five are counted and in the list are bold.

You can find the current list by clicking on Top Cases which brings up the current list.  If you double click on the list item you can see the internal rank in the upper left hand corner of the report.  And this, in my opinion, is where this system breaks down.

The current #1 item is case 9433 (iPhone support).  While it sounds good at first blush, iPhone development is a big break from how REAL Studio works currently, and it requires a lot of intermediate changes and there’s no evaluation from REAL Software on how long it would take to implement iPhone support or what we would have to give up during that time frame.

For example, the current #2 item is case 738 (Controls and Window Backgrounds Flicker in Windows) and is a huge problem for Windows application and my guess is that it hurts RS when Windows users evaluate REAL Studio more than they know.  Would you rather fix this gaping bug or have iPhone support?  Me, I want and need, this bug fixed.

Unfortunately, there’s no way to vote an item ‘down’.  The current system is rigged to only tell how many people think it’s a good idea.  There’s no way for RS to get a feel for how many think the top item is a BAD idea, or don’t think it should be a high priority item.

I personally think iPhone support is a rabbit hole of time and money that RS could use to adding some nice features and cleaning up long standing bugs.  To support the iPhone REAL Studio has to add a number of very important things before it can begin to *start* development:  Cocoa (currently in beta), LLVM compiler support (currently in beta for RBScript) only, new editors, and untold engineering problems on three platforms (is that even possible?).

Cocoa has taken close to two years to implement and ‘new features’ have slowed down (partially from Cocoa and partially from our requests for more bug fixes).  RS has talked about LLVM compiler support – first with RBScript and then for the entire app and who knows how long that will take to get working 100%.  The other items?  Only the Universe knows.

I urge all of you to play around with the Feedback application and find your high priority bugs and mark them as such.  This is the only way (currently) to tell REAL Software on what your priorities are.  If you want iPhone support, that’s great, but I caution you to be careful with what you wish for.

Happy coding!

Fellow REALbasic developer, Christian Miller penned an interesting blog post at http://www.pariahware.com/blog/?p=248&utm_source=rss&utm_medium=rss&utm_campaign=real-software-the-opposite-of-love-is-not-hate-it-is-indifference.  I suggest you read it.

The stage that Christian didn’t add was what happens after acceptance.  This is the point where you ask yourself, “So what am I going to do about it?”  As I see it, there are only three options that are worth talking about.

Deal with it.  Accept the fact that RB is a flawed product and learn to work around its many deficiencies.  We all know that RS is a small company and can’t devote as much resources to it as say an Apple or Microsoft can to their respective development environments.

Leave.  Move on and use the tool(s) that work for you.  I’ve said this to many people:  If you expect RB to make a great Mac OS X only, Windows only, or Linux only application you might be very disappointed.  If you’re looking for a good cross-platform application using one code base it’s one of the few tools available.  The other dev tools available wouldn’t be considered Rapid Application Development tools in my opinion.

Try to change the situation.  This is the approach that I took.  One of my goals with the Association of REALbasic Professionals was to bring the conversation out and be more vocal with what we, the professional developers, need and want.  I found the training materials wanting so I started my own video series available on my website.  I blog regularly about RB here and on the ARBP website.  I’ve written tutorials, answered questions in the RB forums, talked at RB conferences and, written articles.

Without patting myself too hard on the back and injuring myself, I have been a pretty vocal supporter of REAL Software.  Hopefully you all have read the posts where I’ve been just as critical of REAL Software.  I’ve hitched my wagon, so to say, to the REAL Software bandwagon because I like the product, like the people that work there and, it has satisfied the requirements of my company and my clients for a decade.  I’ve been called a shill for the company and I’ve received hate mail for my anti-REAL Software stances.  My point is that I’m not a mindless cheerleader for the product because that does no one any good.  My family and my employees families fates are intertwined with the fate of REALbasic so I need it to be a viable product.

From my perspective the constant focus on new hobbyist users does absolutely no good for my business.  Too often new features are implemented that are ‘good enough’ for the hobbyist but suck for me (think toolbars, the report generator, htmlviewer and Windows flickering to name a few).  The hobbyists can’t pay for advanced features.  Businesses can, and will, if it makes sense for them.

RS is right to be proud that they ‘eat their own dogfood’ and that the RB IDE is made in RB.  That’s great, but making an IDE/compiler isn’t what I make.  Its obvious, at times, that there is a disconnect between what RS perceives we need and what we really need.  I’ve been using RB since the 3.5 days and yet there’s only one Date control, one Calendar control and one alternative to the listbox (i.e. grid).  In the corporate environments I used to work in that’s unacceptable.

I’ve long advocated that REAL Software create an internal consulting group.  Start with one person.  That group bids on potential projects like all the other developers in the network (to make it fair to existing developers, their rate must be HIGH).  When they’re not bidding or working on projects they do two things:  1)  they create real world examples and check each one for each release to make sure they still work; 2) They create training videos and tutorials, and answer tech support issues.

Having an internal consulting group does a couple of things:  1)  they quickly learn the pain of making real world applications in REALbasic; 2) provide valuable feedback to the powers-that-be in RS on what needs to be fixed and in what priority; 3)  it’s a (potential) revenue stream; 4) Makes sure that the documentation and examples really work; 5) Makes corporate users feel better knowing that if their own development team gets into trouble RS can back them up.

The truest definition of insanity is doing the same things over and over again and expecting a different result.  As we’ve seen with some very vocal criticisms (like Christian’s) and others, the perspective is that RS is doing the same thing over and over again and failing.  Unfortunately, so are we, the users.

I’ve written a few times about The Sixty One. I thought it was a great example of a web app that works well.  I was able to discover some great new bands and for a few of them I track their progress to see if they come to town and play.

Unfortunately, The Sixty One is a prime example of how redesigning the user interface can make your existing user base very angry and make them leave.  Common complaints about the new design are “antisocial and unnavigable” and I happen to agree with them.  The new changes made a great music discovery site not nearly as much fun and discover new bands.  It sure looks pretty though.

Microsoft has gone through similar criticism with the Office ribbon.  Some people love it and others hate it.  The few times I’ve used Office with the ribbon I was frustrated beyond belief because of the way *I* learn how to use applications.

A friend recently commented to me that they learned to like the ribbon.  I’m not sure that Microsoft would get that benefit (of time) if Office wasn’t ubiquitous.  I can say that as a Mac user I’m not excited about getting the ribbon in the next version of Office but them I’m already using Pages and Numbers more and more because they do everything I need them to do for far less money and less bloat.

From my own experience, we went through interface changes on Task Timer, our Mac/Windows desktop application that tracks your time.  It’s a very simple interface.  Version 1 and 2 let you track one project/task combination at a time.  People complained so we opened it up to five.  People (mainly lawyers – go figure) said that five simultaneous timers weren’t enough so we made it unlimited.

We rewrote the interface to allow an unlimited number of simultaneous timers and project and task combinations.  The beta users were very happy and we were happy too (since we use it every day as well).  We released and the very first bug report was from a long-timer user who complained that we destroyed the simplicity of the interface.  I guess there’s no winning.  Thankfully, with a few minor tweaks we were able to make that customer satisfied but most users will just walk away in disgust.  It’s not easy to get a second chance.

Every time FaceBook changes their layout there’s always a round of complaints.  I generally fall into the group that is willing to work with it but I do have to admit that I generally don’t mind the changes after I’ve gotten used to it.  But then, I also find that the new interface isn’t that much better than the old one – usually.

I sometimes think that companies redesign their website and products because they’ve got designers on staff and they think the designers need to earn their keep.  Don’t fall into that trap and change the interface ‘just because’.

Interface changes should be well thought out to satisfy existing users and to get new ones.  Doing so without some serious thought and effort, both before and after the change, can result in people abandoning your product or service.  Tough to stay in business that way.

Any other examples of a bad user interface change?

Since REALbasic (now REAL Studio) 2009 R5.1 updated the SQLite database engine the RB Forums have had more than a few RB users complaining that the database no longer works.  Thankfully the community has been able to get the message out that the AutoCommit property of the REAL SQL Database is now, by default, false.  I think it should be true by default and the RS did the users a disservice by forcing this change on us.

As an advanced user I understand completely why autocommit should be false.  However, as someone who has fielded some of the forum questions and have even have this bite me in an old project I can’t imagine why this change was considered a good idea.

I’m not sure if the change fixed a bug or the RS engineers realized that it wasn’t working the way they expected it to but setting the AutoCommit to false, however, breaks a lot of existing programs.  That all by itself, in my opinion, was a big mistake – even if it ‘fixed’ a bug.  Someone evaluating RB for their DB application now sees a spate of “The database doesn’t work for me anymore” messages in the forums.  Are they going to really look much further even if the solution is as simple as db.autocommit = true?

Second, because the change is silent and subtle, a lot of developers were pretty mystified (and pissed off).  Heck, I didn’t spot it until I was doing the REALbasic training videos and realized that data wasn’t being saved.  I’ve been using RB for for over eight years and I spent more than a few minutes scratching my head.  How does that make a beginner feel about REAL Studio?

I know that I should be checking the error condition of the database after every transaction.  I know that I should be handling the commit and rollback on my own.  I know all this and do those very things (most of the time) and yet still I got bit.  I can’t imagine how the rest of the RB universe felt when they finally found out why their db apps weren’t working properly any more.

What’s worse is the Language Reference for AutoCommit is lacking anything close to an appropriate example.  The AutoCommit entry has this to say:

The default is False: Changes open implicit transactions that you must close explicitly. If you set AutoCommit to True, then the database will no longer open implicit transactions for you, and instead, will automatically commit each database change immediately. It is recommended that you leave AutoCommit set to False unless you understand the implications of setting it to True.

How about a little discussion on the implications?  And of course there’s no example of how to properly do this unless you’re smart enough to check out the examples in the parent REALSQLDatabase  entry and smart enough to realize that you also need to read the examples in the Recordset entry.

Let’s be brutally honest for a minute.  Most RB users want their changes to be committed automatically because they’re not SQL guru’s.  They just want their application to work and don’t care about what the ‘best practices’ are for databases.  It’s been a while since I’ve used VB6 and ADO but I don’t ever remember having to tell my data to commit.  I do remember having to add code to start a transaction and commit and rollback my transactions.  So why was this RB change a good one?

Unfortunately, now that AutoCommit has been like this for a few releases we can’t put the genie back in the bottle.  I would ask that in the future that REAL Software deprecate ‘broken’ methods and replace them with a new one so that it’s obvious that something has changed.

Did the AutoCommit change affect you at all?  Did it make sense right away or did you have to hunt the reason down?  Was the change necessary and a good change?

Someone asked me the other day what ‘feature complete’ meant.  I replied that I felt it meant that everything you intended to put into the application is there and not missing.  Other people gave other responses but it got me to thinking.

Here is the definition of ‘feature complete’ from Wikipedia:

A feature complete version of a software is not yet final, but contains all intended functionality of the final version.
Usually a feature complete software still has to undergo testing and bug fixing as well performance or stability enhancing before it can go to release candidate and finally gold status.

I think the semi-permanent beta status of open source and web software skews our expectations.  We’re so used to the term ‘beta’ being applied to software we’ve really lowered our expectations of software.  It used to be that software at the ‘alpha’ stage was feature complete but functionality could significantly change with usability testing.  ‘Beta’ stage was when all functionality was complete and usability testing started, usually by allowing a bigger group to test it.  Any bugs get fixed and a new beta version is released to make sure the bugs were fixed and no new bugs introduced.

Finally, the ‘Final Candidate’, or ‘Release Candidate’ was a fully functional version of the software that if everything worked properly it would be released to the public.

The Wikipedia definition for ‘Release Candidate’:

The term release candidate (RC) refers to a version with potential to be a final product, ready to release unless fatal bugs emerge. In this stage of product stabilization (read QA cycle), all product features have been designed, coded and tested through one or more Beta cycles with no known showstopper-class bug. When a version get to the Release Candidate cycle, only one iteration should be necessary.

Obviously, these definitions are fluid – at best.  Problems discovered late in the beta stage could seriously affect functionality and certainly a major flaw discovered in a Final Candidate could (and should) push a public release back.  If you have a ’set in stone’ release date, however, how does that affect your releases?  I imagine that it severely limits your flexibility if major problems are found – especially if you have some sort of contractual obligations to release.

Is this your understanding of the software process?  Or is software now so complex and so fluid that we need lowered expectations of what software should be capable of doing for us?  Is it okay to release with known bugs as long as it’s ‘good enough’?

If you’ve been reading this blog for any length of time you know that I really like my Sony eReader.  Well, I used to really like my Sony eReader.  Now that the iPad has been announced I look at my eReader with fond memories and can’t wait for the iPad.  My Sony eReader is now dead to me.

The eReader is fine for what it does but it’s a one-trick-pony.  I’ve grumbled on more than one occasion that I don’t like seeing book graphics in 16 shades of gray and the slow refresh rate is annoying (but livable).  Not being able to zoom graphics is annoying too.  The ability to play MP3’s on my eReader is totally worthless (to me at least) since I always have my iPhone with me.  I’ve never used it so why pay for it?

I have an accessory that allows my eReader to be read at night that works fairly well.  But, it uses regular batteries that wear out in a couple of weeks and it makes using the eReader during the day a pain because it makes the text less readable.  The iPad won’t have those problems.

Let’s talk briefly about software.  The Library application that comes with the Sony eReader stinks.  It’s not a native Mac app, it’s not a native Windows app.  It sucks on both platforms.  In fact, I hate it so much that unless I buy a book through their store I use an application called Calibre.  I hate it too, I just hate it much less because it manages my books much better.  iTunes does a great job of managing my music, movies, and podcasts so I can’t imagine that it would suddenly suck at managing my books.

I thought that selling the iPad to my wife was going to be hard but it turned out to the be exact opposite.  She wants one in the kitchen.  Why?  A little background is needed first.

My lovely wife is also a very talented cook.  She’s adventurous and is always trying a new recipe or even making one up from several she’s found on the internet.  She prints the recipe out and then takes it into the kitchen.  Imagine being able to do that from the iPad which she just puts on the counter.  If there’s not an iPhone app for a chef (I bet there are several already) there will be a couple of specific ones for the iPad (soon)!  And with a nice glass screen, there’s not too much worry about getting the device dirty.

The iPad has one huge advantage for me – the app store.  Our family already has 3 iPhones.  Don’t make me count up how many apps we’ve downloaded (both free and commercial) but I’d bet that it’s probably close to a hundred.  When we get our iPad we’ll already have the software for it.  No researching and purchasing new pieces of software that may or may not do what we want – we already have them!

I think the iPad will be awesome for Boomers.  How many of you have Boomer friends or relatives that call you for tech support on the Windows or Macintosh computers?  Show of hands?  Thought so.  The iPad is so for them.  Do any of your friends and relatives call you on how to use their iPhone or iPod Touch?  Didn’t think so.  The iPhone is so simple that hardly anyone has issues figuring it out.

Anyone who says the iPad won’t be a huge for business is nuts.  I have clients, right now, that could sell an iPad application if we converted their app to work on it.  Imagine an HVAC service technician, rather than lugging around a ton of paperwork and a big, clunky laptop, showing up at your house, logging all of his work, including when he arrived, what tests he performed, results, and then showing you the iPad display showing all of this and then billing your credit card directly (though an add-on card reader) and then emailing your the results?

Another example:  My doctor is all electronic and the interface to his current tablet stinks – they all hate using it!  They spend minutes clicking and doing crazy things in the interface.  I can imagine them using an iPad with the keyboard attachment and being more efficient with their time when they use an interface designed around a touch screen rather than an interface meant for a desktop app that’s been forced onto a tablet.

The list goes on but the possibilities are limitless.  You think Apple demonstrating the iWork apps on the iPad was a fluke?  Nope.  Apple thinks this thing is going to sell like hotcakes to business and I happen to think they’re right.

What do you think?

Normally I run REALbasic on Mac OS X and remote debug in Windows.  This works 99.9% of the time but late last week I ran into a situation where I wanted the IDE on the Windows side as well.  So I installed RB and downloaded the plugins that I needed.  Then I started to use RB.

Using RB for Windows was…different.  I’m not sure that I can quantify it other than that it seemed less polished.  It just doesn’t feel like a normal Windows app and it certainly was not as smooth as the Mac OS X version.

The reason I was in Windows to begin with was of tracking down a printing bug that was affecting my product.  Turned out it was the Application.UseGDIPlus property that had been set to true.  The end result was that my reports were ‘blown up’ about 10 times bigger than they should have been.  This has been documented and is <feedback://showreport?report_id=10399>.  Turning off the property fixed the problem.  Some fix, eh?

I don’t think that Windows gets as much attention as the Mac OS X.  Why do I believe this?  The ARBP surveys consistently show Mac users being about 80% of the membership.  Likewise, traffic to this website is roughly 80% Macintosh.  What this means is that beta testers are predominantly Mac based.  I believe that most of the developers at RS are Mac users as well.

Currently, RS is in the transition to get Cocoa out.  It won’t be happening for 2010 R1…so it’s obviously a much tougher nut to crack than they originally thought.  Honestly, I’m not surprised.  Going from Carbon to Cocoa is like creating an entire new platform.  Eighteen months to two years isn’t out of the question for such a big undertaking.

I’m hoping that when Cocoa is out and working great (you think it won’t have some bugs in the first release?) that RS pays a lot of attention to Windows.  They’ve said in the past (sorry no reference for this) that a vast majority of new licenses are Windows users.  But yet, based on observation, the professionals and beta testers are mainly Mac users.  Does that not say something?  Would better Windows support translate into more Professional and Studio licenses?  I don’t know, but I suspect so.

Perhaps it’s time to kill support for Windows 2000.  I’d even suggest killing off XP but I know a lot of places in the world are still actively using it so that’s probably a non-starter.  I believe Cocoa support will effectively kill support for anything less than Mac OS X 10.4 so why not for Windows too?

I suggest that everyone that has a Studio license do a bulk of their work in Windows for a couple of weeks.  More Windows-specific bug reports will (hopefully) get some of the more obvious (and painful) bugs fixed.

What are your feelings about this?  Am I right, wrong, or somewhere in-between?

I’ve said this in a few posts, in RB Developer Magazine, and when speaking at REAL World:  Don’t say anything online that can harm your business image.

Take for example the latest flap in Kansas City over Larry Johnson’s Twitter posts.  Full store here:

http://www.arrowheadpride.com/2009/10/26/1101039/chiefs-rb-larry-johnson-starts-war

I’m not going to defend the guy since this isn’t exactly new territory for the troubled Kansas City Chiefs running back.  In fact, I call him stupid for saying anything on Twitter about his coach, his team and teammates, or his host city.  As a member of any organization you represent the organization that pays you – no matter what.

The fact is, regardless of your business (and playing football is a business), what you say in public, whether in be at a conference, in a restaurant or bar, on Facebook, MySpace and, yes, Twitter can be used against you.  This is why you will NEVER see me talk about sex, politics, or religion because I know it will piss someone off (Even this post will most likely piss someone off but that’s the point!).

With me, I could lose a consulting client or two and maybe lose some software  sales.  I can move on.  I can change careers or I can make amends to rehabilitate my image.  A movie star, professional athlete or politician may not have that luxury and they may cost themselves a job and potentially millions of dollars in income.

Look, I know he’s human.  We all make mistakes and say stupid things.  I wish I had a dollar for every time I said something I’d like to take back.  But I’m not a professional athlete, politician or have a super high profile position and salary.  If I did, though, I’d be more circumspect in what I said especially if I knew the media was going to parrot what I said.  There are certainly plenty of examples of high profile people using social media properly and not airing their dirty laundry for the world to see.  Likewise there are high profile people in bad situations that keep their message positive.

In Johnson’s case he may have hurt his chances of every playing football again.  I expect the management and coaching staff of the Kansas City Chiefs and their fans won’t mind at all if LJ sits out the rest of the season and ends his career sooner rather than later.

How many times will they take the verbal abuse from a player that has always been a problem child?  LJ’s had more chances than most – mostly because of his athletic ability.  I think he’ll learn the lesson the hard way – through his paycheck.

This week it appears that Microsoft screwed the pooch and lost everyone’s data that was using Sidekick on T-Mobile.  Microsoft should have known better and had proper backups and Hitachi (who was doing an upgrade for them) didn’t check either.  Expect some major finger pointing (and lawsuits) going on in the upcoming weeks. Regardless, there are multiple layers of failure and plenty of blame to go around.

It’s why I chuckle when people talk about ‘cloud computing’ being the wave of the future.  I have no doubt that we’ll see more cloud computing but there are just certain things that don’t belong in the ‘cloud’ and should be taken care of by your own IT department.

I did a fair amount of work a few years ago on a commercial accounting application and every now and then the boss would get all excited about cloud computing and he’d kick the tires and make some noise about moving the entire operation towards it.  At first blush it makes a LOT of sense to have the software and data reside elsewhere because it puts the burden on the host company to keep the software up to date, upgrade the hardware on a regular basis, have regular on-site and off-site backups and have decent security.  And then you realize that its strength is also a weakness as the Microsoft case has shown.  You are depending TOTALLY on someone else doing the right thing.

The other reason is the data.  For many companies their data IS their business.  It’s their competitive advantage.  You really trust all the pipes between your office and the cloud computing servers?  Sounds paranoid but this is your sensitive data you’re talking about, right?  How many stories have been published about SSN and credit card numbers being compromised (at the minimum) and outright stolen (at the worst) in the past couple of years?

If you’re in a larger metropolitan area you probably have decent internet access, with decent speeds, that never goes down.  There are a lot of places even in the United States where this is simply not true. I’ve always enjoyed pulling the network cable from a computer when someone is on their high horse about cloud computing.  Tough to get work done when you can’t load the software or the data.  At least with the software and data on my computer and local network I can still get work done.  My job requires internet access and I can tell you that when my internet goes down I’m not very productive (and keep in mind that I’m in a top 40 metropolitan area with all underground utilities!).  I’ve also had web servers get attacked and be so unresponsive that they might has well have been shut down.

In the long run, can you go to your boss and guarantee (because it might mean the difference of having a job or not, after all) that the data is 100% secure, backed up and available 24/7?  Food for thought, no?