BKeeney Briefs

I was reviewing my list of REALbasic training videos the other day to see what I had missed.  At the top of the list were the DataControl and DatabaseQuery controls.  Technically, the DBQuery isn’t a control, but you can put it on  the window like one, but for the sake of discussion we’ll include it.

I think I gave up on those controls about the same time I gave up on a binding (which is no longer part of REALbasic).  While I think they have their place, I sort of look at them as being too basic and too simple for most of my needs.  There’s nothing about those two controls that is favorable in my mind.  I duplicate their functionality using my own code and have far better control over the results.

Will I do training videos on them?  Probably, because it makes the set more or less complete.  As with some other controls and classes that I haven’t used much in RB career I’m sure I’ll learn something by doing the videos.  Perhaps I’ll change my mind.

Some controls, like the OpenGLSurface, the various sockets, and RBScript objects aren’t used very often either, but when you do they are very powerful and can do a lot of things.

Here’s my list of controls that I’ve never used in any REALbasic project (that I can remember):

• DataControl
• DatabaseQuery
• ImageWell
• NotePlayer
• Placard
• Spotlight

I was tempted to include the Microsoft Office objects, but I’ve used them in a couple of Windows-only projects.  My only beef with them is that their documentation and examples are unbelievably bad.

What is your least used or least favorite control in REALbasic?

We’ve all met people like this.  Within ten minutes of meeting them they’ve worked it into the conversation that they belong to Mensa, have you heard of it?  Oh, you haven’t, it’s for people that are really smart.

Really?  I’m happy for you.  Really, I’m being honest.  But I don’t care.  You see, I don’t care about your intellectual IQ.  I care about how you relate to other people and to the problems at hand.  Do you listen to me to learn or to put up with me?

(Before I get the hate mail, I have plenty of friends that really belong to Mensa and have never mentioned it until they asked me if I was interested in joining.  I’ve always declined, thank you very much.)

I’m being cynical because people like this drive me nuts.  If it’s their idea it’s THE PERFECT SOLUTION because, well, they’re the smartest people in the room.  Never mind if you have practical real world experience that says that idea, while good, isn’t the ideal solution.

I’m not a farmer, but I grew up in farm country.  All of my neighbors were farmers and while most of them never had a college education they were practical people.  The old joke was that you give a farmer, baling wire, gum, and a welder, they can fix almost anything.  They were practical smart because plants and animals either do well or they don’t and if they don’t they didn’t stay farmers very long.  The best part, is that they never went around bragging that they were very good farmers – they didn’t have to nor did they want to.  Heck, most of them would admit they weren’t very  smart, but they knew how to manage their business with thousands of different tasks, machinery, animals and plants and make a profit (in most years).

The smart people, the smartest people in the room, don’t bother to ask the pertinent questions, or make measurements, or ask for previous results of tweaks because they are, well, the smartest people in the room.  They assume they are an expert at everything they put their mind to.

I look back at Apple in the late 90′s and early 2000′s and I think they had a fair amount of the “Not Invented Here” syndrome where if they didn’t make it, or code it, it wasn’t going to make it into their products.  We all know that Apple was in dire straights back then.  When Jobs came back to Apple he got rid of a lot of projects and now their very focused and they use a ton of ‘open’ standards in their operating system.  Why?  Because they get to expand upon the ideas of hundreds of thousands of developers rather than a few thousand.

In my engineering days I saw plenty of engineers that would re-engineer a solution because it wasn’t the way they’d do it.  It generated a lot of unnecessary work and wasted money.  The software industry isn’t any better.  They feel that because they have user interface designers they need to tweak the user interface on every release.  Every major new version adds a bunch of new ‘features’ that the average person won’t use because they need to keep the developers busy.  That’s called software bloat.

If I had one bit of advice for people that own their own business is this:  hire people that are smarter than you.  I mean it.  Hire people that are as close to an expert in their field as you can afford.

Let them challenge your (the boss’) ideas and assumptions.  Make an atmosphere where their ideas get a fair hearing without shooting them down right away because they’re not smart enough.  If you listen to the smart people you’ve hired to get things done you will probably learn a few things.  After all, don’t smart people want to learn new things?  Don’t smart people want their ideas to be challenged?

If all you do is hire ‘yes’ people then your product will suffer.  Your product won’t have focus.  Ideas that should be shelved for another time get put in now because the boss wants it and no one can tell him no.  Ideas from customers are ignored because they’re ‘just customers’.  When customers quit using the product, ask them why – you might just learn something.

Neither do you want design by committee.  What an awful thought that is.  It’s the exact opposite of being focused.  A good leader or leadership team will pick the good ideas out and let their people run with it.  The bad, or not so good ideas, will be stored away and revisited every now and then.  What was a bad idea might be a good idea in a year or two.

I’ve rambled enough for now.  I’m sure you’ve all had ‘leaders’ in your organizations that were never open to ideas unless it was their idea.  They used circular reasoning to shoot good ideas down and to keep their ideas alive.  Are you still with that company?  Is that company still around?  Is it financially stable?  My educated guess says that they’re not as smart as they think they are and you’d agree.

In my previous blog, one of the commenters asked me about my thoughts on the new LLVM backend compiler that RS is implementing for REAL Studio.  I’ll first start by saying that I am not a backend compiler expert, nor want to be.  Much of what I’ll write about I’m getting from sources that are in the know, as they say.

What exactly is LLVM other than a fancy acronym?  It stands for Low Level Virtual Machine and is a compiler infrastructure.  It was started in 2000 at the University of Illinois and in 2005 Apple hired some of those original authors for their development system.

RB currently uses a custom written backend compiler.  As you can imagine, maintaining a compiler is a lot of work and writing optimizations is not easy.  LLVM was designed for multiple layers of optimization including compile-time, link-time, run-time and even idle-time.

What does LLVM mean for REALbasic applications?  It means that applications should be smaller and faster.  Code that isn’t used will be removed (dead-stripping code).  Currently RB can do this but it’s not exceptionally efficient (but really not all that bad either) as it which leaves some unused code compiled into your application.  For most of us this isn’t a big deal, but for many that start a project with a standard toolset, they might be introducing some inefficiencies into the final product.

Switching to LLVM is great news, though.  Smaller, faster, better are all things to strive for.  Without giving away too much information, the RBScript compiler is being reworked to use LLVM.  It’s a good first step.

But that’s all it is.  If you’ve not used RBScript, let me tell you, it’s not REALbasic.  One of the most powerful features of REALbasic is the cross-platform debugger.  Run in one environment while debugging in the other.  Even when you are debugging locally (on the same machine in the same environment) you’re ‘remote debugging’.  If my source is correct, switching to LLVM will require rewriting the entire debugger because the LLVM metadata system is different than RB’s debugger map system.

Since LLVM uses different metadata properties the current introspection system will break and have to rewritten.  Plugins will also break.  The IDE, the plugin system and even the reporting engine are a heavy consumers of introspection.  So going to LLVM means a huge portion of the product needs to get updated.

Rewriting the debugger is not a trivial task.  To do this the RIGHT way is a huge job that could take a couple of strong backend compiler developers 6 to 12 months to fully implement.  Even hacking it together is probably a 4 to 8 month project and it would still take some time getting the remote debugger to work properly.

If all this sounds daunting and kind of scary, well, it is.  Switching backend compilers is not something to do on a whim.  It has to be well thought out and resources have to be allocated properly.  The roadmap for features that will not be added during the transition time need to be thought out properly as well since limited resources are a fact of life in all organizations.  A small organization needs smart long-term planning.

Make no mistake, though, the backend compiler switch promises to be take a while.  It basically rewrites major portions of the product which will lead to some subtle and not-so-subtle changes.  The risk is high and it will affect EVERYONE.

There’s been some talk about all the ‘freebies’ we will get when using LLVM (such as 64 bit support).  Not true.  Using LLVM gets you ‘closer’ but it still won’t be free.  Switching to LLVM removes one of the many tasks involved with such support.

With all that said, I think moving to LLVM is a must.  If RS wants to support different platforms it’s a smart move going forward.  The optimization capabilities look very promising and will be welcome to many users.  It IS the right thing to do.  Just be prepared for some bumps along the way.

One final word.  I’m a passionate RB user.  I’ve also been a project manager where I think about the bumps in the road before they happen.  I’m not an expert at this stuff, though, so any misconceptions or mistakes are entirely my own.

The March/April 2010 edition of REALbasic Developer Magazine hit my inbox this morning.  Besides the normal BKeeney Briefs column Marc Zeedar and I have a spirited debate on whether or not REAL Software should devote existing resources to making REAL Studio work with iPhone apps.

Note the italics on ‘existing’.  While I think it would be a nifty idea, overall, I question the wisdom of diverting resources from an already small development team to a product that might be doable.  Is this a Mac OS X only product or is it cross-platform?  I seriously doubt that it will be cross-platform but perhaps I’m wrong.  The point is that there are a ton of issues to figure out and then the question then becomes, “What are we going to give up in the desktop versions while this is being developed?”

Other thoughts:  Apple makes a boatload of money from developers buying Mac hardware and this product has the potential to take that revenue away.  One could certainly argue that it has the potential to sell more iPhones/iPads/iPod touches because more applications will be available.  But Apple has 140,000-ish apps right now.  Would 10,000 more, or 100,000 more really mean anything to Apple?

It also has the potential of being a potential support issue for Apple.  Assume for a second they allow RS to make iPhone apps.  The RB framework has a bug (because that’s never happened), or Apple changes the SDK one day and doesn’t give RS advance notice (Apple is secretive, no?), and now tens of thousands of RB iPhone apps no longer work.  Will the developer, RS or Apple get the blame?  Apple.  Just like how Microsoft gets the blame for crappy drivers and crappy 3rd party apps made by bad developers, Apple would get the blame.  Apple guards the keys to their kingdom very closely because they want it to be associated with a classy, premium product that “just works”.

Anyway, you can read the debate between Marc and myself in the magazine.  My guess is you can figure out my viewpoint.    Marc argues, the opposite.

My regular column talks about making your projects more Agile-ish without going full-bore in using the Agile process.  It’s not as hard as you think and your clients might really like it.

Your thoughts?