LiveCode vs Xojo

I have been a Xojo developer for many years and I make a decent living at it.  That doesn’t mean, however, that I don’t look around at other development environments every now and then.  I do this because it makes good business sense to keep my options open.  This week I looked at LiveCode after a reader asked me to.

LiveCode (formerly called “Revolution”) is a unique development environment that has been around since 2001.  It was inspired by HyperCard and due to its lineage it uses a Card and Stack metaphor to represent windows, objects, and applications.  To put it more in Xojo terms you can think of a window as being a Card and the entire application as a Stack (of cards).  Dialogs and other objects can then be sub-stacks.  LiveCode can make Mac OS X, Windows, and Linux desktop applications, cgi-like web apps, and mobile apps for iOS and Android.

Its scripting is a natural English-like programming language that presumably makes it easy for casual programmers to get started.  Another interesting feature is that there is very little difference between ‘development mode’ and ‘debugging mode’ and switching between the two is literally just a button.  This means that you can run LiveCode commands practically at any time without the need to compile the application first.

The IDE has a variety of windows.  The Application Browser shows you all of the objects in the stack and lets you open each card into an editor.  The editors let you put controls on the Card (layout) and each card and UI object has a number of Messages that are similar to Xojo events.  LiveCode does not have an all-in-one window like most other IDE’s.  At first, I found the individual windows to be refreshing but after I while I found that I was fighting with background application windows.  I’m sure this is something that becomes more natural with usage but I had issues with it.  I’ve always wondered if Xojo’s all-in-one window IDE approach was really the ‘best’ approach to a development environment and now I see that I prefer it as it eliminates the distractions of other windows.  Also, Eclipse, Visual Studio, Xcode and Xojo all have all-in-one IDE’s so I this it safe to assume that most developers are comfortable with this style.  You may find LiveCode strange if coming from an all-in-one IDE.

The LiveCode scripting language definitely takes some time to get used to.  The natural English syntax seems inviting but after 30+ years of coding in various languages I found it frustrating.  It’s wordy and not exceptionally compact in its meaning.  If you don’t already have any programming experience this might be good for you.  If you’re coming from a different language you might be as frustrated as I was.

Xojo events are relatively easy to find and implement.  You simply right-click on an object either in the Navigator or in the Layout Editor and add Events to the object and it’s added into the code waiting for you to add your own code to it.  The object messages in LiveCode are not so easy to figure out, in my opinion.  To figure out the events I had to go into the documentation (which was decent, in my opinion), and had to look them up and then type them into the Script Editor.  I’m sure with a little time and practice I would pick up the messages that I use most often, but it is a hindrance to picking up the language.

LiveCode Dictionary

LiveCode API Dictionary

 

The Xojo Code Editor has a pretty good auto complete.  Auto complete means that when you start typing, say “SQLite”, and if there are either language keyword matches or variable matches the eclipses (…) is shown and if you hit the tab key a list of available properties and methods are shown to you in their proper context.  This makes discoverability much easier.  LiveCode has no auto complete in their Script Editor which means you have to look up the commands before you start typing and you won’t know if they’re correct until you run the project.

LiveCode has objects but they don’t have the same Object Oriented nature as Xojo.  In Xojo you create an instance of the object and then get/set a property or call a method using the dot notation.  Thus opening a database in Xojo means creating a new instance of the Database, setting a FolderItem property on that object.  Then calling the CreateDatabaseFile method on that same object and it returns a true or false to indicate success or failure.  All of that revolving around the same object (database).  The same thing in LiveCode requires less coding steps but there is no dot notation and it’s definitely more procedure driven.  Each method is its own call – not part of an object – and means that you’ll spend more time looking at documentation to discover them.  I feel that Xojo’s discoverability is superior to LiveCode.

LiveCode is not a strictly typecast language meaning you can use a variable anywhere at any time.  This means that writing scripts can be very quick but it also means that introducing errors is easy and with larger projects it might be hard to find errors.  Xojo, on the other hand, is strictly typecast and the compiler will tell you if a variable is not defined or if you try to put the wrong type of data into a variable.  There are plenty of other languages out there that don’t require variable type declarations but I never have spent much time with them.  If you’re used to them it’s probably no big deal but I tend to like the compiler to warn me early and often of any potential issues.  Another little thing about the language is that to assign a value to a variable using the Put command rather than an equal (=) sign.  In LiveCode you would say:

put “ABC” into myStringVariable

In Xojo this same thing would be

dim myStringVariable as String = “ABC”

LiveCode Create DB

Creating an SQLite Database File using LiveCode

Xojo Create Db

Creating an SQLite Database File using Xojo

 

One of the major drawbacks that I discovered early on was that LiveCode does not make native looking applications.  The good news is that PushButtons look the same on each platform (no mean feat) but it also means that those Pushbuttons don’t look native on any platform.  There are commercial plugins available to make LiveCode applications look native on each platform.  I don’t believe that the plugins are using native controls either so this means that an OS update might ‘break’ the look of an application until those plugins are updated.

LiveCode Mac app

LiveCode App running in Mac OS X

LiveCode Ubuntu App

LiveCode App running in Ubuntu

LiveCode Win8

LiveCode App running Windows 8

 

Xojo is not perfect in this regard as not all of its controls are native on each platform either.  It does, however, use them whenever possible.  Another drawback to Xojo is that control features are often times the lowest common denominator between Mac, Windows, and Linux for desktop platforms.  This is more for feature parity than any malfeasance on their part.  Xojo web apps and iOS apps use native controls.

LiveCode, like Xojo, lets you create external libraries using C++.  LiveCode calls these Externals while Xojo calls them plugins.  It appears that there is an active community of developers and an active 3rd party development community for LiveCode.

Unlike Xojo, LiveCode comes in two different varieties:  Community Edition and Commercial.  The Community Edition is open sourced and free but limits you to open source and GPL applications.  If you are interested in LiveCode this is where I’d recommend that you start.

There are four different types of commercial LiveCode licenses.  The Indy Commercial license costs $299/year per seat and lets you do closed source and royalty free commercial apps with a $500k revenue limit (how this is enforced I have no idea).  The Business license costs $999/year/seat and eliminates the revenue limit.  The Pro license $1,999/year/seat and gives you more personalized service and a Premium license is $10,000/year for 3 seats and gives you priority support, use of their test suite, extensions, priority features (whatever that means) and a LiveCode conference ticket.

LiveCode also has a membership program that costs $99/year ($25/year for students) and gives you exclusive membership benefits and helps supports the continued development of the platform.  You also get access to over 100 training videos and access to the LiveCode Conference simulcast.

What I Liked About LiveCode

I found the LiveCode Start Center to be clean and uncluttered and useful.  It has four main areas, Projects that shows your recent projects, Getting Started that has handy links to the some beginners videos and guides, Resources that takes you to tutorials, sample stacks, the community forum and their API dictionary, and finally they have a Sample Projects list that has a sample projects in it.

The LiveCode website also does an excellent job of pointing out 3rd party commercial and non-commercial extensions and what they can do for the developer.  They also allow user reviews of the extensions so it makes it easier to make a purchase decision.  I have no idea what it takes to get listed on their website or if LiveCode takes a cut of the revenue but it’s something I wish Xojo would do a better job of helping their 3rd party developers market.

I also found it refreshing that their API documentation allowed user comments.  I really wish Xojo would do something similar because I feel that we, the user community, could add some really useful comments to the documentation.  While I like the Xojo documentation I feel it might be better served by opening it up a bit (with moderation).

LiveCode does deploy for Android which might be a huge bonus for some.  Assuming I could get a UI that looks native it might be the one thing that would make me look at LiveCode with any seriousness if a client asks for Android deployment.

Finally, the fact that part of LiveCode is open sourced is interesting.  They successfully ran a KickStarter campaign to open source the product in 2013 and successfully did a campaign on their own website to fund HTML5 web deployment in 2014.  I don’t know about anyone else but I would help fund certain items for Xojo development even if wasn’t open sourced (perhaps a better grid control?).

What I Disliked About LiveCode

If you’re coming from C++, Java, or any object oriented language I think you’ll find the lack of ‘objects’ to be disheartening.  Add to it that there is no auto complete for the Script Editor and I think it’s a deal killer for me.  Those two features make discovering events, properties, and methods so much easier without having to constantly check the documentation and I think it’s a huge adverting for Xojo.

The lack of strong datatypes, while not a deal killer, scares me a little.  I want to be warned early, often, and loudly when things go wrong and strong datatypes are something that I really find attractive in a programming language.  If there’s a data conversion going on it’s because I want it to happen (don’t get me going on Xojo variants – they’re evil – get over it).  The natural English scripting language also puts me off simply because it’s unnecessarily wordy.  Again, if you’ve never programmed before this might be an advantage.

The lack of native looking controls is also huge drawback for me.  Xojo apps will try their best to look native (though Linux apps require more of a nudge than Mac/Win apps) and while not perfect, out of the box, Xojo apps are generally native.

Conclusions

Is LiveCode worth a look?  Sure.  Like any development environment, if it speaks to you and you can get your projects done in it then it’s the right one for you.  For me, Xojo is a better language, with a better IDE, and has more features that I want.  Xojo is only lacking Android support and I’d probably look more at Xamarin than LiveCode for a variety of reasons.

If LiveCode works for you that’s great.  This review isn’t meant to be overly critical of the tool but as an existing Xojo developer I don’t see enough reasons to switch from Xojo development to LiveCode.  Feel free to leave comments below on anything you feel I missed or got wrong.

The State of the Xojo 3rd Party Developer Market [u]

BKeeney Software offers a variety of Xojo developer tools for sale. BKeeney Shorts is a reporting tool unlike anything else in the Xojo kingdom and allows you complete control over your reports. That is its strength and also its weakness since you have to fully code your report. We also offer a Calendar class for use in desktop applications, a cross platform Spell Checker plugin, and ARGen that creates the classes that ActiveRecord uses to make database coding easier and quicker in Xojo.

Over the years we were approached by developers that were leaving the Xojo market and wanted a home for their product. When True North Software decided to exit the Xojo market we purchased the rights to Formatted Text Control, RB Code Reports and a number of other Xojo related tools. When Pandaware left we picked up Simple Help Editor and Styled HTML Field. Many people were asking for PDF classes and had fond memories of Fireye Software’s PDF classes so we tracked down Asher and acquired those too.

We purchased these products from their respective owners either because we already owned the products or had a use for them. In some cases we simply updated the source code and in some cases we started a complete rewrite to suit our needs. This means that in addition to the original thousands of man-hours the original developers used to create them we’ve invested significant time and effort ourselves to work on them.

BKeeney Software can’t exist on the sales of these developer products. Developer product sales are lucky if they top 20% of our annual income. Most years it’s less than that. Our second highest income earner is our Xojo Training material but, by far, our best income source is our consulting services. With multiple Xojo developers that makes sense. Not only can we throw all of our developers on a project we can (and usually do) all work on separate projects. When one of us is idle (which thankfully isn’t very often) we find time to work on our applications and developer products (and me on training material).

I was on the receiving end of a grievance on the forums this week where I was accused of not delivering updates that I promised on one of the products. If I did nothing but work on our products I’d be out of business in short order and that product would just go away and who knows if anyone would pick them up.

This got me thinking. Am I unique in this position? So I queried some other Xojo developers to find out what the state of the Xojo 3rd party market is like and if they would share their thoughts. I received more information back than I expected.

Almost all of the developers I contacted said that product sales were a minor portion of their income with most stating it was less than 20% of their income. Jérémie Leroy has a full-time job and the Xojo business is just a happy sideline. Sam Rowlands said there was no way the sales of his developer products comes close to paying for itself. And,one of the more well known figures in the Xojo community, Christian Schmitz said, “Even with the scale I have with MBS myself. Consulting keeps the company running.”

From these statements, it’s pretty obvious that the 3rd party market, while not exactly stagnant, isn’t thriving either. Everyone I talked to has other sources of income besides their developer tool/utility sales. Part of this is probably because the Xojo market is small. Another reason might be the hobbyists that Xojo attracts and they simply don’t have the means to purchase tools. Another possibility is that Xojo has ‘good enough’ tools built-in and newcomers don’t need the more advanced commercial, add-ons.

One of the interesting comments I received from several developers was that it was those that purchased the cheapest version of their products (some offer encrypted and non-encrypted versions) created the most work for them. I’ve seen this myself with our encrypted source code that it seems to generate more support tickets than the full-source versions. Based on this feedback I am seriously considering removing the encrypted versions from our store and simply selling the full-source versions. It’s interesting that our one product that doesn’t have encryption (Formatted Text Control) doesn’t generate that much support help despite it being one of the largest and most complicated products we sell.

All of the developers I contacted felt that the future of Xojo is bright and holds promise. iOS development in Xojo might become as big as desktop and web which means new customers for their products. The new framework causes concern for many in the Xojo community but the developers I talked to were ecstatic that Xojo was listening to our concerns and making incremental changes to the new framework based on that feedback.

The 3rd party Xojo development tool market is tough business to make a living at. The fact that half our products came from developers leaving the community says something. That some of the most well known and respected voices in the community can’t make a living selling Xojo developer tools and have other sources of income is also telling.

So what can Xojo do to help us out? Growing the user base is the biggest thing they can do and it seems that having the iOS version is a step in growing the platform. One area of concern, though, is that many Windows users are unhappy with Xojo right now. They feel, rightly or wrongly is besides the point, that the focus has been so Apple and iOS oriented the past couple of years that they feel unwelcome. Some focus on making the Windows experience better would be reassuring to them.

I also think that Xojo could do more to promote the 3rd party products. Perhaps the Xojo Developer Evangelist could pick a product to review each month. Xojo Developer Magazine does reviews like this but it doesn’t receive the eyeballs that the official Xojo site gets. Personally I’d offer a discount for the people that purchase via the review. The market isn’t THAT big and it would be a good way to show off some products and generate sales for developers that are starving for income. More income means more of time for product development and everyone wins when that happens.

I feel the future is good. More Xojo users means more product sales (hopefully). This, in turn, means we can spend more time on those products and pump out updates on a regular basis. Until then, us 3rd party Xojo developers will continue with our labors of love and put updates out when we can.

What do you think of the 3rd party market? What could Xojo do to improve it?

[Update:  ]

After looking at our 2014 numbers our total developer products and training sales was LESS THAN 10% of our total income.  In 2013 the amount was more but amounted to less than 5% of our annual income (consulting was VERY good that year).  In other words, if we relied on our developer products and training to make a living we would quickly go out of business.

Seriously, why do I even bother with developer sales?  Just using them and updating them for ourselves would be cheaper in the long run.

Client Red Flags

I’ve talked before about those little things that prospective clients (and sometimes actual clients) do that should give you cause for concern.  These are those things that should be red flags and make you reconsider taking them as a client, or not keeping them as a client.  We recently took on a new client that had already burned through another Xojo developer before coming to us.

I’ll start off by saying that we have an entire stable of clients that came to us after they had tried out another developer.  Roughly 75% of our long term clients have come to us this way.  For some, the developer left the industry and recommend us to their client but for some the Xojo consultants had failed to deliver a working application even after quite a bit of time and money.  The clients came to us and they’re happy that we have multiple developers and have a breadth of experience that is hard to find elsewhere.  We’re also not going away anytime soon.

This client should have raised enough red flags for us to avoid from the start.  But, honestly, that’s easy to say in retrospect.  Sometimes you just won’t know until you work with them for weeks and sometimes months.  Plus, it was a smallish project that was only a couple of weeks long.  What could go wrong, right?

The clients first developer underbid us by a grand total of 10 hours but had significantly lower billing rate.  A couple of months later the client parted ways due to lack of progress from the first developer and called us back.  Red flag number one, in my opinion.  Clients have every right to be price conscious but one warning sign is if they’re trying to get the project done ‘cheap’ and ‘quick’.  While possible they also need to be flexible and this client was anything but.

The second issue with the client is that they kept using phrases “we want it exactly like this,” with ‘this’ being a VB6 application that looked like they coded it in 1995 and an HTML website that harkened back to the 90’s as well.  Even if Xojo could create such an application (it can’t without significant work) I’m not sure I would simply because creating a 20 year old GUI isn’t something I strive for.  We were going to create modern GUI (nothing crazy – just want Xojo gives us) with a database backend so the application could scale.  But they demanded flat files and a UI that looked ‘exactly’ like their prototype (which was non-functional).  Their reasoning?  Because they understood it and ‘their generation’ understands that look.  Hm…okay.

I guess my biggest issue with this client is they chose Xojo – not us.  There was nothing in the project spec (a VB6 app, a simple HTML web site, and some phone meetings) that said it couldn’t be done in Xojo and when we heard ‘just like this’ we translated this to mean ‘as close to this in Xojo as possible’ and when we didn’t make it look like the 90’s website they were mad and cancelled the contract despite us redesigning the app twice in attempt to mollify them.

In retrospect, the client doesn’t really want a Xojo developer.  They want an HTML and php developer that will do exactly what they want.  No more.  No less.  The signs were there from the beginning – we just failed to see it.

In the long run it’s just another red flag example that I hope to learn from and I hope that you don’t have to go through either.

Naming Conventions

If you don’t have standard naming conventions in your Xojo (or any other language for that matter) project you need to start NOW.  I mean it.  Open your IDE of choice and start looking at your variable names.  Can you tell at a glance what type of variable it is?  Better yet, can you tell what it does?  Or do you have a bunch of x, i, y, and z’s floating around in your code?

What about your TextFields?  Do you name them so you can tell their function or do you simply use the default name that the IDE gives you?  How do you tell the difference between TextField1 and TextField2?

Literally, the first thing I do when handed an OPC (Other Peoples Code) project is to look at the control names.  If I see TextField1 and TextFieldX I will almost always turn the project down.  But if I see txtName and txtAddress I know that I can figure out the code without constantly having to look at the Layout Editor.  The point is that controls are referenced in Xojo code all the time so if you’re naming your controls so that their function is obvious, the code will be obvious too.

The same goes with variable names.  I will prepend arrays with ar so that an array of MyClass will always look like aroMyClass.  My dictionaries always have dict in the front.  Colors always have c prefixes and so on (see chart below).

Do I use the occasional i, x, y and so on?  Absolutely, but they are throw away variables that are inevitably part of a loop of some sort.  If I’m using that variable for any other reason I will always name it something useful.

Variable names are important.  Rarely will you see me using iTemp as integer.  Instead, I’ll use iTempIndex which will at least tell me something about the variable.

I dare you to look at a project you did a year ago and open up any random method in it.  Can you read the code without referring to the Layout Editor?  I know that I’ve refined my own coding standards because of this.  If you’re not learning from your past mistakes why keep doing what you’ve always done?

I can hear some of you now.  Standards…Pft!  I don’t need no stinkin’ standards.  Think again.  I’m not here to tell you what those standards are just that you have them and that you are consistent about them.

Do what makes sense to you.  I looked at hungarian notation (http://en.wikipedia.org/wiki/Hungarian_notation) and I can see why people call it a different language.  While I’m sure it has many fine qualities it seems to make more work for me in figuring out what the variables are doing.  It’s way too complicated for Xojo.  For me, at least, simpler is better.  Plus, I’m not sure that a strongly-typed language like Xojo is in need of such strong naming conventions.

Using naming conventions for your controls and variables is an easy way to simplify your life and your clients’ life (if you’re handing code over).  Remember, you’re not just coding for the here and now, you’re coding for someone that will look at the code 6 to 12 months from now.  That someone might just be you!

Below is values right out of our new developer introduction document:

Variable Prefixes
Datatype Prefix Example
string s sName as string
integer i iCnt as integer
double d dAverage as double
dictionary dict dictNames as Dictionary
date dtm dtmModified as New Date Assumes I care about the time
date dt dtToday as new Date assumes I do NOT care about the time
class reference o oMyClass as new clsMyClass
color c cHighlight as color
folderitem f fPic as FolderItem
private property m miCnt as integer
boolean b bVisible as boolean
memory block mb mbBuffer as MemoryBlock
window win winMain
class name cls clsMyClass
array ar arsNames() as string ardAverages() as double aroMyClass() as clsMyClass
Control Prefixes
Control Prefix Example
Pushbutton btn btnSave
Label lbl lblCaption
Listbox lb or lst lbPeople or lstPeople
StyleGrid sg sgPeople
TreeView tv tvSections
TextField/TextArea txt txtPassword
CheckBox cb or chk chkEnabled
BevelButton bb bbSelect
ComboBox cbo or cmb cmbUserType
PopupMenu pm pmState
ProgressBar prog progUpload
Scrollbars see example common practice to use vScroll and hScroll
Radio Buttons rb rbOption1
Canvas cvs cvsGraph
TabPanel tab tabMain
Toolbar tb tbMain
PagePanel pp or page ppSection
Menu menu menuPopup
Container Control cc ccDetails

Xojo Webinar: Xojo Consulting

For some time now Xojo has been doing webinars on various topics.  It’s a great way to learn about Xojo.  In addition to being live (where you can ask questions) they are recorded too.  As time goes on the webinar archives become a really nice resource for new Xojo developers and even experienced developers can learn a few things too.  If you’ve never been to the archive, check it out!

Join me at the next Xojo webinar, Tuesday, July 22,  where I’m guest host!  I will share my 13+ years of Xojo consulting experience.  Learn some of the great things (and not so great things) about being a Xojo consulting.

Come prepared with questions!

Register now at http://xojo.com/support/webinar.php

You Have a Contract, Right?

Writing software for others can be a tricky profession.  The client often has totally unrealistic expectations on how software development works.  They give vague requirements (or none!) and expect you, the developer, to read their mind and produce an awesome application.  And therein lies the problem, because there’s a wide difference between their requirements (or lack thereof) and the finished project.  A handshake and a verbal agreement just isn’t good enough – You need to protect yourself (and the client) with a contract and spell everything out.

If you don’t have a contract already, my preferred place to begin is by going to Docracy (www.docracy.com) and looking up contracts.  These forms aren’t perfect, but they’ve been looked at by lawyers, and in-lieu of hiring your own lawyer, a heck of a lot cheaper.

The basic contract has little over a dozen sections.  I’ll just highlight a few of the sections that seem to grab peoples attention.

A payments section is obvious.  It gets into the details of how you’re getting paid.  More detail is good.  What’s the rate?  How long is it good for?  Is it a fixed bid?  What is the payment structure?  Do you have a separate rate for bug fixes and for how long?  When can you revisit rates?  Do you take check or credit card?  Do you have a fee for taking credit cards?

The expenses section should detail everything that you are paying for out of your own pocket (like computers, development software, etc.) and what you expect the client to reimburse you for.  This could include travel expenses, special services, software, or plugins required for the project, postage and courier services or any number of legitimate things.  The point is that you need to document it!

One section that has caused me some issues over the years was the intellectual property ownership section.  Every client wants to own the code you’ve written and this section gives any patents or trade secrets developed for the project to the client.  I have, as many consultants do, a stable of controls and classes that I reuse on nearly every project which really can’t be the clients’ property when the project is done.  This is where the consultant’s materials section comes into play.

Consultant’s materials are the tools, or pieces of code, that were in existence before the work began that you use to get the job done.  You can give the client nonexclusive rights to the software with some exceptions (spelled out of course), or you can attempt to retain the rights to your own software.  Regardless, this section should be read carefully so that you and the client thoroughly understand the implications.  It has been my experience that this section almost always needs an edit or two to satisfy everyone.

A lot of clients also require a confidentiality agreement section that says that you won’t talk about your work for the client to others without permission from the client.  Sometimes they also want a non-compete section stating that you won’t work on similar software for a certain number of years.  Make sure that you understand the implications of these sections because it might mean you lock yourself out of an industry!

All of the above is fairly generic and is applicable to nearly all contracts.  In my format, the exhibit document is where a bulk of the details occur.  Here is where I list my deliverables, the client deliverables (I don’t like doing graphics so I usually require that the client do them), a listing of any requirements that I’ve received so far (referencing emails and other documents if need be), assumptions that went into the bid, payment schedule and amounts and milestone dates.  As you can image, the exhibit may be much larger than the rest of the contract.

In the client deliverables section, I always state that the client is responsible for final application testing and that they are responsible for end-user support.  The reason that clause is in there is that a client assumed I was doing all the testing and was going to perform end-user support.  This is why writing everything down is so important!

One of the assumptions I generally add into my Xojo projects is that Xojo can actually do what I, and the client, assume it can do.  I only had one issue ever come up and because of that assumption we were able to negotiate a slightly higher contract price to purchase a pricey third-party control.

In the exhibit I add a section that describes how long after the final sign-off I’ll fix bugs for free.  I also state the rate for the following year on program changes (new functionality, not bugs) and when I can renegotiate pricing.  This section can be contentious.  I’ll fix true bugs for a long time, but a lot of times the client doesn’t understand what a bug really is and how it’s different from their poor (or nonexistent) requirements.  If you find a problem client, this will probably be one of the areas that causes you grief.

There’s a lot of information that will be in your contract.  It’s designed to protect you and your client against poor assumptions.  It provides a way for you to handle the client and set their expectations upfront.  In the long run, a good contract will be the roadmap of your projects.

Why have a contract?  Because not having one may cost you  a lot of money.  I turned down a project a few years ago because the prospective client balked at having to pay money up front.  In indignation he claimed in 30 years he’d never paid anyone up front.

He then proceeded to go through the rounds of contractors and they all turned him down for much the same reason.  Finally, he found a developer that was looking for some extra money but already had a full time job.  He did the work (without a contract and without any up front payment).  And, as you can imagine, the client shafted him in the end.  Said that it didn’t work as promised so therefore wasn’t going to pay.  The client was full of it because he walked away with the source and never looked back.

The developer lost thousands of dollars and had no way to enforce it since he didn’t have a contract in place.  Even having a contract won’t stop a client from not paying but at least with a contract the developer could have gone to small claims court to recover some of the money.  No contract meant no such recourse was available.

I think we all have contract horror stories.  Have any that you’d like to share?

Be Paranoid About Your Data

Last week wasn’t a very good week.  Over the weekend the hard drive on my iMac failed and by failing Mac OS X said it couldn’t repair the drive so it came up read only mode.  So I did the sensible thing and copied the entire contents to my external Drobo (essentially striped RAID).

Then Monday morning the Drobo wouldn’t boot up.  It would just do a continuous boot and restart.  Not good, but at the end of the day all of our most important stuff, the source code for projects, is stored on a commercial source code hosting service.  In case of theft or disaster of my equipment I’m only down as long as it takes me to buy a new computer and download the repositories.

The Mac hard drive was replaced by Monday night and by Monday afternoon Drobo tech support had the Drobo back up and running.  They didn’t give a reason but I suspect that because the Mac had hard crashed a few times (due to the bad drive) it got into a state that it didn’t know how to recover from.  But it works and I didn’t lose any data.

Tuesday when things started to go back to normal we couldn’t reach our source code hosting service, Code Spaces.  On Twitter they said they were experiencing a DDOS attack and I didn’t worry to much about it.  They’re the experts, right?

By Wednesday they still weren’t back up.  A little concerned I went to their website and found the message that you never want to hear.  They accounts had been hacked and ALL of their repositories had been deleted.  Oh, and pretty much immediately they are ceasing operations as a company.  You can read more about it at http://www.codespaces.com and http://www.electronista.com/articles/14/06/18/hosting.company.returning.what.data.it.has.left.financially.crippled.by.attack/

So much for the offsite backups.  The fact that the backups could be accessed through their Amazon Web Services account should give anyone pause for concern.  Is your web services company really paranoid enough to protect your data?

I know more than a few people have given Xojo some grief that their security for Xojo Cloud is over the top.  Maybe it is, but then you hear stories like this and you start to wonder if maybe being overly paranoid is a good thing.

So here is my advice.  Have multiple sources of backups.  Keep one source in a safety deposit box and update it regularly.  Use a commercial host that you trust.  There’s no guarantee they they won’t be the next Code Spaces and get hacked but hopefully this incident was a warning to them to be more paranoid and strengthen their security procedures.

I know of developers that backup everything to a thumb drive on their keyring.  I’m not sure that’s entirely secure but if that makes them feel better so be it.  At least their source code is always with them.

While last week was not a good week at least I’m learning to be even more paranoid about my data.  Being paranoid about your data is a good thing.

Classic Visual Basic Is Truly Dead

Developers love Visual Basic.  The site http://www.classicvb.org/petition/ has received well over 14,000 signatures since its inception in 2005.  In the user forums for Microsoft Visual Studio there is a place where developers can make suggestions.  This one http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/3440221-bring-back-classic-visual-basic-an-improved-versi wants to bring back class Visual Basic.  Since December 2012 it had received over 7,400 votes.  Microsoft essentially told VB6 developers to kiss off this week.

The only bit of good news, in my opinion, for VB6 developers was that the VB6 runtime will continue to be supported through 2024.  So, VB6 users, you’ve got 10 years to figure out what’s next.

The VB6 runtime it is still a component of the Windows operating system and is a component shipped in Windows 8.1. It will be supported at least through 2024.

The 1100 (and growing) comments to this post are pretty much what you’d expect.  There are a lot of frustrated VB6 developers that feel Microsoft has abandoned them, at best, and, at worst, actively screwing over one of the most vibrant developer communities on the planet.

Many VB6 developers feel that .NET is inferior to VB6 but yet Microsoft is confident that VB6 developers will somehow migrate to .NET.  I just don’t see this happening.  Oh, I’m sure some will bite the bullet and learn .NET but the prospect of learning a new language and rewriting their apps does not make many happy.  VB6 was effectively killed 10 years ago and yet there are still lots of VB6 developers out there.

Many will be looking at alternatives because Microsoft is not the 95% market share behemoth it once was and VB6 was, after all, Windows only.  I you have to go to the trouble to learn a new language and rewrite all of your apps why not look at something that can work on Windows and Mac and possibly Linux as well?

I spent many years working in VB6.  I liked the language, I liked the IDE.  It had some awful quirks that drove us nuts but they were well documented quirks and were relatively easy to work around.  When I first encountered Xojo (then REALbasic) I felt like I found VB’s kissing cousin.  The IDE’s were similar, the language was similar and it was relatively easy to convert code and community was outstanding.

After twelve years of using Xojo I can say it’s superior in some ways.  First, it’s kept up to date and gets roughly 4 updates a year.  This is both a good and bad thing.  Good because when Apple (and to a lesser extant Microsoft and the Linux Distro’s) change things you’ll know that it’s just a matter of a few months, usually, before a new version of Xojo is released.  Unfortunately this makes Xojo a moving target which is part of the reason why there aren’t any books on Xojo.  It gets written and by the time it’s published it’s already out of date.

There are a number of things that VB6 was just not good at.  Subclassing controls was impossible and we never got threads to work right without causing serious crashing issues (I believe I recently saw a post where they got threading working properly in VB6).  But that still leaves all the other things that were feeling their age in VB6.

I’m biased for Xojo.  I think it’s worth taking a look at if you’re a VB6 developer.  Is Xojo perfect?  Hell no.  The developer community is much smaller and there aren’t nearly as many control options.  And some of the controls, the grid in particular, are inferior to what many are currently using in VB6.

Xojo is, in many respects, a compromise.  All of those fancy grids you see in Windows apps usually don’t exist on Mac OS X and Linux.  Mac OS X apps are generally built with a different UI mindset so the the grids aren’t nearly as busy.  If you planned on doing the same thing in Xojo you will be in for a rude awakening.  Not that you can’t make a complicated grid, but you’ll spend a lot of time getting it to work and even then I’m not sure you’ll be happy with the results.  Plus, Mac users are a finicky lot and if it looks like a Windows port they might reject your app.  But then again, does the utility you wrote for your company really need a fancy UI?

Xojo is very cool sometimes.  The ability to remote debug applications from my Mac to a Windows or Linux computer is very handy.  And the fact that a Windows machine can build for Mac OS X and Linux, for console, desktop and web apps, is also very nifty.

Take a look at Xojo (it’s free to try!).  It might be a good solution for you.  My advice is to not try to ‘convert’ your VB6 app using The Migration Assistant or any of the conversion tools available.  There are just too many language and control differences to make this feasible.  From experience, you’ll spend more time fixing code than if you had just started from scratch.

My other bit of advice is to not assume Xojo and Xojo made apps work just like VB6.  They don’t.  Take the time to read the documentation, look at the example apps, and visit the forums when you have questions (you’ll have many).  The Xojo community is very welcoming and eager to help.

Finally, I am a consultant and if you need assistance getting into Xojo we can help.  My team has rewritten dozens of commercial VB6 apps over the years.  If you’d like a quote feel free to download our VB6 analyzer tool at http://www.bkeeney.com/vb2rbconversion/.  We also have over 50 hours of Xojo and Real Studio video tutorials available to subscribers at http://xojo.bkeeney.com/XojoTraining/ where we’ve helped thousands of developers get a handle on Xojo.

If you are a VB6 developer, Xojo might be for you.  Welcome to the Xojo community!

 

Custom Programming

Does your customer really need the type of custom programming you’re selling?  I often get a request for a quote that involves fairly standard business applications such as accounting and contact management.  It’s hard to justify,  to myself at least, why they’d want to spend tens of thousands of dollars when they could spend merely hundreds of dollars on off-the-shelf software.

Off-the-shelf software has some advantages over custom programming.  It’s generally cheaper.  It’s also available immediately, rather than the months (or years) it takes to develop and debug a custom application.  The off-the-shelf software usually has pretty good technical support and a community behind it that can answer those tough questions.  The customer also knows it’s likely the company behind the commercial software will be still be in existence for many years.

Custom programming, on the other hand, is expensive and time consuming.  If the customer wants you to write a QuickBooks killer they’d better be prepared to wait a while and spend some serious money.  Creating software that competes with established, feature-rich applications is a daunting task.

I am sometimes amazed at the reactions from customers when I give them estimates.  Really!?  You thought writing a QuickBooks clone would take 3 months and only cost $10k?

Most contract developers don’t provide much technical support for the product they’ve developed, leaving it up to the customer to fend for themselves.  Some clients are technically savvy, but most aren’t.  Is the customer going to fix the code themselves?  It’s been our experience that even the few clients that know Xojo aren’t capable of changing any code other than the most trivial – otherwise they’d have written it themselves.

Clients that are selling the application commercially are sometimes unprepared to handle tech support and that’s a problem as well.  If they can’t answer basic tech support questions are they going to rely on you to answer those questions?  Are they paying you to do this?  We had one client that assumed we would be providing free tech support, forever.

Is your custom programming business going to stick around for the long-haul?  Will the customer be able to come to you in five years and have you update their application for Windows 7 or Mac OS XIII or the current flavor(s) of Linux?  The customer wants and needs long-term stability.  I good portion of our clients have come from Real Studio and Xojo developers that are no longer consulting.

With all the problems associated with custom programming, why should anyone spend the money on it at all?  The customer gets exactly what they asked for.  If they’ve done a good job explaining their requirements and you’ve done a good job implementing them, they have something that makes their business very effective, very efficient, and is tailored to their business model.

Custom software might be an asset to the client in the event they sell their business.  Some of this depends upon the contract details you signed (you do have a contract, right?) before you started the project.  A lot of clients are going to want some sort of clause that allows them the rights to sell the software (with source code) to another party.

Custom software allows for additions and changes to occur over time.  Off-the-shelf software may be cheap, but try getting Intuit to change the way QuickBooks does their payroll or the way they handle payments.  Custom software allows the customer to grow their software as their company grows.  If the customer wants to integrate CRM functions into their accounting application this year and add event scheduling next year they can.  It’s really only a matter of your time and their money.

When talking to a potential customer for custom programming, be honest.  Tell them the advantages of custom programming.  You also need to be honest about the negatives as well.  A big part of dealing with clients is managing their expectations on what you can and can’t do for them.

Thankfully, by the time a client gets to us they’ve already explored off-the-shelf solutions and have ruled them out.  Usually they have a very specific need that can’t be addressed with the one-size-fits-all commercial application.

Have you ever convinced a client to use off-the-shelf software rather than your custom written solution?  Other thoughts?

Differentiating Your Services

There are hundreds of consultants out there doing the exact same thing you do.  They’re hustling to sell their services to the very same people you’re trying to sell to.  They don’t live in New York city or San Francisco and can live on $15/hour.  How can you, a good developer, compete with overseas programmers or newbies?

Let’s be honest.  If the client is evaluating potential developers solely on price then you probably don’t want them as a client anyway.  That’s not to say that price should be ignored because a client that’s not frugal with their money is a problem too.  But, it is possible to win a bid even with a higher end price.

So how do you differentiate yourself from the cheap programmers?  The first thing to have is a page on your website that shows previous projects.  This shows potential clients the type of work you’ve done before.  You have to be careful about violating any Non-Disclosure Agreements you have, but for the most part you don’t have to get into specific details about a project to portray the type of work it was.

If you’re just starting out, your previous projects page is going to be sparse.  Another drawback is when your previous projects page doesn’t show the skills the client is looking for.  Unfortunately, the only way to get around this problem is to be upfront with the client and let them know you’ve done the research and have a plan.

Do you have off-site storage of source code?  If you’re working out of your house (who needs an office anyway?) you should probably have automatic backup of source code to an off-site facility.  In the event of a disaster like a flood, fire, earthquake or someone breaks into your house, this is a simple and inexpensive way to protect your work.

We use a Subversion host that gives us gigabytes of storage that amounts to hundreds of Xojo projects files along with documentation and other supplementary info.  The host itself has offsite backup storage and hourly backups.  Does this sound paranoid?  You bet it does!  Your code is your money maker and the client isn’t going to be willing to fund several more months worth of work because your hard drive crashed or your laptop was stolen and you have to recreate your work.  They don’t care, they just want the project done.

Bug tracking systems like Bugzilla, Mantis and many others are good open source software applications that make bug tracking cheap and easy.  Using a bug tracking system is light years ahead of working strictly through email, if for nothing more than the documentation features and audit trail features.  The client can log into the system and see a bug’s status and add additional information.  You, as the developer, can request additional information, close a bug, or merge it with another one.  A good bug tracking system is a must on large projects or projects with multiple developers.

Oddly enough, the other thing that can differentiate yourself from other developers is your contract (you do have a contract, right?).  A good contract is not only protection for you and your client legally, it is also a way to document what you will and won’t do.  It’s the first step into managing the expectations of the client.

Contracts can be a pain to create.  Start with a standard contract.  I’ve been pretty impressed with the documents at www.docracy.com.  Once you have one you like you can add to it.  We use a standard boilerplate contract that is fill-in-the-blank for the basics (name, address, etc) and has general responsibilities for us and the client.  We constantly refer to Appendix A that lists all of our deliverables (source code, installers, documentation, etc), client deliverables (graphics, timely testing, etc), a brief description of what the code will do, and the payment terms.

Price is important and you’ll lose some clients because of it.  It happens.  But using some of the tools and techniques we’ve talked about you can differentiate yourself from the cheap and inexperienced developers.

What things help differentiate you from other developers?