BKeeney Briefs

This will probably be the last post of the year so I can spend some quality time with my family.  Have a very happy holiday season.  For those celebrating Christmas, have a very Merry Christmas.  Have a joyous and safe New Years as well.

One thing that’s come up recently (and more than once actually) is the need for training materials for REALbasic.  I’ve seriously been thinking about doing video training sessions and offering them through the BKeeney.com website as a subscription service and streaming video (physical DVD’s are a possibility but increases the initial startup expense and I want to avoid physical inventory that’s dated).

Any sort of video training will take a fair amount of time to complete.  Just covering the basics of REALbasic will take months to get something out the door.  Add in the Rapid Release Model and I will always be aiming at a moving target.  How many hours of video is needed to put the shingle out?  What’s a good price (keeping in mind that while doing the videos I’m not doing as much consulting work)?

My guess is that most RB developers reading my blog have been using RB for a while but I’d like to get your opinions on this as well:  How much of a beginner level versus intermediate and advanced material?  And even for beginner material do I even need to go so far as to explain what variables are?  In other words do I assume the student knows absolutely nothing about software development or has at least a little knowledge of some other language?

In that same light, would problem solving videos be better than a more traditional approach?  For example, I could do a video training on “How to Open files of a particular type” versus exploring the various things in the FolderItem.  Each approach has its merits and drawbacks.  What do you think?  I could argue both ways.

Regardless, the one thing I think that will happen is every video will be tagged with the RB objects used and perhaps even the object methods used.  So doing a search on FolderItem would result in a bunch of videos that use the folderitem.  If you did FolderItem.Item you’d might find videos that iterate through the items in a directory and so on.  The drawback to the tags is that any complete application examples will use a lot of different RB objects which then might make the tags worthless because a search will hit every video.

For what it’s worth, there is some existing REALbasic training.  They have 7 hours of RB training and a subscription gives you access to a LOT of other applications (which I could never offer).  I’ve watched all the free training and it seems to do an adequate job but it hasn’t been updated since 2007.  I plan on updating more often than every two years – especially if I can pay my bills from it!

I’ve also done a minor example application and recorded it.  With a little editing and speed up of typing sequences it’s at two and half hours and I don’t consider it done yet!  Add in an IDE walk-through, some Remote Debugging, and miscellaneous topics and I probably have 4 to 5 hours of relatively decent video footage.  I think I can do it, I just need some positive encouragement or negative feedback before I commit myself.

At this point, dear readers, I’d like your thoughts.  Good or bad idea?  What are the pitfalls that I haven’t thought of yet?  Will people actually pay for an on-going video series on REALbasic?  Should the emphasis be on beginner, intermediate, or advanced material?  Should I let the members determine the production order via an online poll?

My review of REALbasic 2009 Release 5 (and 5.1) is up on the ARBP website in the blogs section.  Direct link.

I’ve been using 5.1 exclusively the past week or so and it seems to be stable so now I can move up from R3.  Thankfully, the huge SQLite bugs introduced in R5 have been fixed in R5.1.  Reporting still has issues though.

I was reviewing this years client list and the work we’ve done this year.  We have a lot to be thankful for and we really appreciate their business and like to send them a small token of appreciation during the holiday season.  We hope they come back for more work and the gift, trivial really, is just a way of saying thanks.

I started thinking about our clients.  With the exception of a handful, most of them are not in the Kansas City area.  Heck, most of them aren’t even in the Midwest.  So what this means is that we never see our clients in a face-to-face meeting and have to rely upon phone calls (both traditional and via Skype), emails, instant messages, and the occasional screen share or video conference.

This makes managing a project harder in my opinion.  There is so much information that gets passed when you’re sitting across from a person that you’d be hard pressed to write it all down.  It’s hard to get that same level of info electronically.

I get a chuckle when I hear about companies looking to offshore their development work to developers in developing countries.  Sure, it’s possible and you might be able to save some money but there’s a hidden cost.

In an Cutter Consortium survey Link over 20 years and 8000 projects they found that offshore projects reduced the cost of projects to $3.2 million versus the $3.5 million it typically cost by doing it on-shore.  From a time perspective the on-shore project took 12.6 months and the offshore took 9.6 months.

The real kicker is that the defect rates for offshore projects were an incredible 7565 versus the 2702 for onshore projects.  So even though the offshore project cost less and took less time, the company had to fix nearly three times more defects.  In the long run I’m not sure the offshore projects saved anything.

In the same study Agile methodology came out looking like a winner.  The average agile project took 7.8 months with a cost of $2.2 milling with a defect rate of 1372.

Last summer we worked on an agile project.  It takes some time getting used to but after the initial learning curve the project went very fast and the client was very happy with the results.  If you have a big project you should probably think about using agile.

I apologize for digressing from the main topic.  Certainly one of the of biggest challenges with a long-distance client is communication.  I suspect this is why the offshore projects have higher defect rates.  Everything needs to be written down and communicated – mostly via email.  Throw in cultural and language differences and you have a recipe for misunderstandings (if not outright disasters).

A couple of things that I’ve learned is that the communication skill of each client is different.  Some can handle an email with a list of questions.  Others can’t so you end up with single point emails.  Email management is a must!

We use a bug tracking system and encourage our clients to log in and use it.  Most get it and love being able to track what’s been fixed and what hasn’t.  Others just won’t use it (despite regular prodding) and resort to emails.  Depending upon the size of the project, it might just be easier to transcribe those emails into your bug tracking system.

Long-distance clients need special attention.  They need reassurance that you are really working on their project.  For some clients we do a 3P report where we report on Progress, Problems and give the Plan for the upcoming week (sounds sort of agile, no?).  With the web becoming an integral part of our lives and business, learning how to work with clients from anywhere in the world is an important skill.

How do you deal with long-distance clients?  Do you try to have a face-to-face meeting with them?  Do you think you do anything special for your clients?

I originally intended to use this space to announce that my review of REALbasic 2009 R5 was posted on the ARBP site.  I wanted to say that this release is a good one that it adds some nice new features, enhances some old features and offers a plethora of bug fixes.  Instead, I’m going to go on a rant about the lack of quality in recent REALbasic releases.

Before I start my rant I have to preface this by saying I know and respect many of the REAL Software employees.  I am friends with several current and former employees and am on friendly terms with many of the employees as well.  This is not personal.  I’m a supporter of REALbasic when I can but given the debacle of the R4 and R5 releases I have to call them out on the carpet for some well deserved tongue lashing.

Quite frankly, their quality control sucks.  Release 4 had bugs in their new Build Automation and Reporting tools which made it unusable for me (but okay for most users).  Release 5, which had a shortened schedule, has an ugly SQLite bug that has the potential to silently create an infinite number of bugs.

This new bug was caused by a change to the column type returned by the recordset in SQLite databases.  I’m not sure of the details but it has something to do with the index number.  It’s supposed to be zero based but was one based and now it’s reversed (or visa verse – like I said I’m not sure).  I don’t know if if was the documentation what was wrong or the implementation in the SQLite plugin but regardless, the change was not done properly because it potentially affects all existing SQLite users.  Ideally a new API should have been introduced and the old one deprecated.

You can see this manifested in the Reporting tool in R5.  If you look at my example project of REAL Reports from the ARBP source code repository you’ll see that a varchar column is interpreted as an integer.  (Note:  To use in R5 you’ll have to update the namespaces in the project).  The sName field returns what looks like a number rather than the text data that is in the database.

This is not good.  It indicates that quality control is poor at REAL Software.

I’m part of the beta program.  I tested the reporting tools and submitted a bug on November 18th about an unrelated bug having to do with Group Footers.  This bug did not manifest itself then (I’m not sure how far in the beta process it was but it’s late considering that it was two weeks before release).  So this means that major functionality changed late in the beta program.  This is doubly worse is that last week was a major holiday in the United States and most people take additional days off.  They made a major change with fewer beta testers than normal in the pipeline.

To say that R5 was released too early is an understatement.  It’s been a year since REAL Software released their build engineer and senior engineer and up until R4 I was happy with the quality and stability of the builds.  After R4 and R5, however, I now have to seriously test the official release to determine if it doesn’t have a major bug that affects me or my clients projects even though I tested it during the beta program.

To say that I’m disappointed is an understatement.  I feel that my time in the beta program has been a waste.  Why am I spending valuable time beta testing if RS isn’t going to give us the time and listen to us?  If the testers say don’t release because of ‘x’ problem shouldn’t that be a clue that something is wrong?

Who’s in charge of development?  Aaron (senior engineer) and Nathan (build engineer) used to manage the releases but now I don’t know who has the final say.  The development of REALbasic is too important to leave to the schedule of sales and marketing.  Someone has to draw the stick in the sand and say, “NO!” when it’s not ready.  It’s not JUST REALbasic that is affected – it’s everyone that uses RB that gets hurt by RB bugs.

If RS isn’t going to properly test their own product what does that say about their process?  I’d rather there be fewer new features and bug fixes and more time spent on testing so that each release is rock solid.  It sure beats what we’ve had these past two releases.  Let’s hope that we don’t have to wait 90 days to get a fix for Release 5.

Thoughts?