How Not to Get Screwed By Clients

Excellent article over at Fast Company that’s a really good read.  http://www.fastcodesign.com/3024819/how-not-to-get-screwed-by-clients?partner=newsletter  I’ll wait for you to come back.

Get it in Writing

Never do any work unless you have it in writing.  If you do happen to be talking via phone or video send an email afterward what you think you heard.  It’s up to the client to tell you differently then.

Don’t do any work without a contract.  You can find some simple contracts over a http://www.docracy.com.

No Spec Work

We get this line a lot, “There’s additional work in the future.  What kind of a price break can we get on this small starter project?”  Really?  You want the discount, now, before we’ve established that we can work together?  Um…no.  Discounts are for when you trust each other and it’s a really big project (as in you don’t have to find additional work).

Upfront payments & never send final work before final money

If you ever have a client tell you that they’ll pay you afterwards just walk away.  Seriously.

I turned down a project a few years back for a lot of reasons but one of them was that my gut was telling me the client seemed ‘slimy’.  For one, he insisted that in his 30 years of working with developers no one had EVER asked him for money upfront.  We said no and he went on his way.  He shopped his project around to a number of other consultants who also turned him down (for similar reasons).

Finally he found a Xojo developer that was just doing consulting for fun (really!) and who didn’t ask for any money up front.  What could go wrong, right?  He agreed to the project (no contract, by the way, but that’s another story) and delivered the project.  Guess what, the client stiffed him.

This developer did the work with no down payment and gave the client the final product before payment.  If he had at least gotten a down payment he would have been compensated a little.  Instead he got nothing.  Make sure you have your bases covered.  And of course with no contract in place the developer has no recourse.

Look for red flags.  Run for the hills

Don’t be afraid to run away from a prospective client.  Trust your instincts.  The linked to article has some good ones (including the This will lead to paid work line).  Some of our red flags:

• No specifications.  It’s common for a client to not have the fine details but when they have zero idea what they want then it’s time to move on (or charge them to write the specifications).

• Worse yet, worthless specifications.  I once had a client give me an 80 page specification document that made zero sense.  We had four people review it and all of us came out scratching our heads.  Funny enough, after meeting with him it was written exactly the way he talked.  Sadly, I should have walked away from that project even though the alarm bells were ringing.

• They fight you over every penny.  I’m not saying that the client shouldn’t be prudent with their money, but if they are professionals looking for professional help they should realize that your time, effort, and experience is not cheap.

• You’re the third or fourth developer they’ve either approached or worked with.  There’s a reason why they keep not finding or losing developers.

There are more red flags but those are a start.  What are some of your red flags with clients?

Busy Month

I haven’t been posting much this month for a reason.  This is, in all seriousness, the busiest January we’ve ever had for Real Studio consulting (and we’ve been doing this for over ten years!).  All three of our full-time Real Studio developers are maxed out on projects and not just on single large projects either.  We all have multiple projects awaiting our attention as soon as we have the time.

Being that busy is always a good thing-bad thing proposition.  My backlog of Real Studio training videos just gets bigger by the day.  Oh well, they’ll wait until I’m slow or want to do something completely different for a few days.

I’ll admit that I have been very critical of Web Edition – especially when it first came out.  I felt that it was released too soon with obvious bugs and holes in the frameworks, wasn’t adequate testing, and was without features that were necessary.  A lot of that has changed recently (though WebMoviePlayer still burns a hole in my stomach) and we’ve found that most projects these days have some sort of web component in them.  Web Edition fills that need for us and while it may not be the best, fastest, scalable, or comprehensive web platform to deal with it has increasingly become a part of our standard package.

I mention this because all three of our developers are working on projects where Web Edition is used to some extent in conjunction with the desktop apps.  I think it safe to say that about 1/4 of all our Real Studio work is using Web Edition.  Not bad considering it wasn’t really usable until mid-Summer 2011.

Web Edition is much like Real Studio desktop apps.  You have limited options and there are a bunch of compromises that you might not be able to live with.  If you can live with the compromises, development is very fast.  While deployment can be kind of a pain it seems that most of them revolve around three or four issues (FTP transfer, file permissions, 32 bit compatibility libraries, and the .htaccess file).  The fact that you can reuse much of your code between desktop and Web Edition is icing on the cake.

Anyway, that’s what’s up with us.  How is 2012 starting for you?

Visual Basic 6 TIOBE Index

The TIOBE index for programming languages is an interesting visual perspective on programming languages.  Take a look at the graph for the trend of Visual Basic since 2002.

Visual Basic seems to have taken a big hit at the end of 2004.  I’m not entirely sure of why this happened because .NET had been released in February of 2002 in Visual Studio.  Visual Studio 2003 was released in April of 2003 and the next update was Visual Studio 2005 which was released in November of 2005.  Vista was released in January of 2007 so I don’t believe it has anything to do with the operating system either.

Perhaps what’s interesting is that it nearly regains its former popularity in about two years.  Could this have been a reaction that people found .NET to not be as easy to use as VB6?  I know that some people were dismayed that VB.NET wasn’t much like VB6 and abandoned it – especially since Microsoft operating systems weren’t breaking their old VB6 apps.

Since the midway point of 2009 it seems like the bottom has dropped out in VB6 popularity.  Could it be because Microsoft officially ended support for VB6?  Again, speculation on my part, but that is about the time that I started seeing an influx of requests for quotes from people wanting to convert their VB6 apps to Real Studio.

Another huge drop happened in early 2011.  Was this due to the confusion of whether or not Windows 8 will support VB6 applications?  Perhaps.  I have seen another increase, in the same timeframe, of people looking to convert from Visual Basic to Real Studio.

Is Real Studio (i.e. REALbasic) the right choice for your Visual Basic 6 application?  The answer is a qualified maybe.  If you want one code base that works the same on Macintosh OS X, Windows, and Linux and perhaps a similar code base for a web app (Web Edition has separate UI classes than the desktop) then Real Studio might be a good fit.

If you’re looking at converting to Real Studio please do your homework.  Learn a little bit about the language (<shameless plug>Like my training videos<\shameless plug>) and work with it a bit.  Do NOT depend upon any VB6 to RB converters working – there are simply too many things that REALbasic is better at.  You’re better off rewriting your app to take advantage of moderns things like subclassed controls and threading rather than try to force a Real Studio app to behave like a VB6 app.

My final bit of advice is to forget about your ActiveX controls you’ve spent so much money on.  They probably won’t work and they won’t work on the Mac or Linux anyway.  Find and switch to an equivalent, if possible, but you’ll probably create some of your own subclassed controls.  In the long run you need to think in RB-speak rather than VB6-speak.

Real Studio, in the long run, is pretty inexpensive compared to Visual Studio, in my opinion.  I know people that thought of nothing of dropping over $1000 per year per developer on control suites.  Real Studio is much cheaper from that perspective since subclassing controls, canvas controls, and container controls eliminate the need for much of those expensive suites.  The drawback is that you end up doing the work yourself rather than some other developer.  And some things just can’t be done in RB that you might have come to expect in VB6 (like specialized controls in a grid cell) simply because on the Mac or Linux there is no equivalent.

If you want to convert your VB6 app to Real Studio, you can take a look at our conversion page at http://www.bkeeney.com/consulting/vb2rbconversion

Developer Referral Program

We’ve been Real Studio consultants for ten years now.  We also belong to the Real Studio Developer Referral Program.  We get a fair amount of consulting business from the referrals.  It’s probably safe to say that over 50% of our business is a direct result of the Referral Program.

We answer most posts that potential clients add at the Find a Developer Page and while we don’t get an answer from everyone we do talk to quite a few.  What amazes me is how few developers are responding to referrals.  A potential client told me today:

You were the first (and so far, the only) to reply.

This was a fairly straightforward project that was for a cross-platform app.  The client even knows what technologies they want to use.  How hard can that be?

The Developer Referral Program cost $495 for 12 months and $295 for 6 months.  This isn’t a lot of money (it used to be a lot more when it was bundled with priority support plans) and it can easily be made back on a single project.  If you’re looking for Real Studio development work, this is a good way to get into it.

What’s great about the Referral Program is that the people asking for developers already believe they need Real Studio.  There’s no selling them on the benefits of Real Studio – they’ve already decided on it!  Talk about shooting fish in a barrel.

Anyway, I just thought I’d share this with you.  Every Real Studio consultant I know (and I know more than a few) is busy.  There is enough work for more Real Studio consultants.

The Plugins/Libraries We Use

We do a lot of projects every year.  Every project is different but we have a core set of third party controls and plugins we use on a regular basis.  Here’s our list.

Monkeybread Software  http://www.monkeybreadsoftware.de/realbasic/

I know a lot of people complain about the Monkeybread plugins but we find them to be most useful.  Time is money and chances are good that if there’s a system declare you might need they’ve already done it.  Plus, they are very responsive to bugs and changes to Real Studio.  They’ve been very proactive in developing Cocoa compatible plugins.

The Chart Director plugin is a wonderful charting tool.  It has a ton of features and is very fast.  We’ve used it on a number of projects now and we’ve been very happy with it.

Automatic Updater Kit:  This set of classes and utilities is must have for Mac and Windows apps.  On Mac OS X it uses Sparkle to do automatic app updates and on Windows you can set it to use an installer file.  We’ve automated this (using IDE scripts) to the point where we only need to run one command line function to finish everything (and that only because we haven’t automated the Inno Setup process yet).  We recently modified the code to do some data file updating as well.

Einhugur  http://www.einhugur.com/index.html

We use much of this suite as well.  Real Studio does not ship with Date and Time or Calendar controls.  The Einhugur set comes with nice versions of those as well as a wicked fast TreeView and StyleGrid controls.  They have a number of other libraries and controls that are very useful including their E-CryptIt plugin that offers many encryption, encoding and hashing techniques.  Einhugur has also been very proactive in developing Cocoa compatible plugins.

Formatted Text Control  http://www.truenorthsoftware.com/formattedtextcontrol/

If your app needs true RTF file support or need inline graphics then this is a must have tool for you.  This is a set of pure RB classes (unencrypted) so you can dig into the guts and make your own modifications (or fix a bug or two as we’ve done over the years).  This is good code to learn from as well.  They recently added masking which is a nice replacement for the crappy masking that Real Studio provides with the TextField control.

RSReport  http://www.rothsoft.ch/realbasic/rsreport/

If you need anything other than basic (and I mean REALLY basic) reporting the built-in reporting tool isn’t all that impressive.  We’ve moved almost everything over to RSReport.  It’s great because you control everything.  It’s awful because you control everything.  Reports take a little longer to design and get running but the drop-in report viewer and the export to PDF capabilities more than make up for it.  They do have a Report Designer component but I’ve never gotten it to work well in my own projects so I’ve not used it.  Their lack of support is a little disconcerting but so far I’ve been happy with it to take the risk.

eSellerate  http://www.esellerate.net/

We use the eSellerate plugin for our own products.  It handles licensing and registration and though they take a cut off the purchase they’ve been fairly proactive in updating their service over the years.  Their RB plugin has NOT been updated for Cocoa so we really have no idea what we’ll use if they don’t update it.

What are you using a lot that’s not in our list?

Lessons Learned the Hard Way

At the Atlanta Real Studio Summit a few weeks ago several presenters were showing off beta code or showing code that they had modified earlier in the day.  Of course you know what happened – there were embarrassed developers saying, “I swear, it just worked a minute ago.”  It’s the Law of Demo’s and happens as soon as you use code not thoroughly tested before you show it off, or when you veer from your script.

When I told my son that they violated the Law of Demo’s he replied rather quickly, “Oh, you mean they tried to modify their program the day of the presentation?”  Smart kid, but then we had learned that lesson the hard way during our First Lego League robotics season.  Trust me, there’s nothing worse than your team (full of 9 and 10 years olds) feeling horrible because they didn’t keep a backup and the modified program just doesn’t work.  Lessons learned the hard way are always the best.

The same goes with consulting and contracts.  I’ve recently been in a spat with a client over unpaid invoices.  Because this person was a referral and well known to many in the Real Studio community I made a verbal agreement to do a lot of work for him.  It was a Web Edition project, which was new to me at the time, so I agreed to a lower rate since it was a good way to immerse myself in a new technology.  In general, I thought the project went rather smoothly while using alpha and beta editions of Web Edition.

Normally, all communications are via email and text iChat so I have a record of all conversations.  This client, however, likes to talk via video iChat.  The drawback is that iChat doesn’t automatically save these (there is an option but I didn’t find out about this until I started doing the research).  So now that the project is done, the client is 60+ days past due on his invoices and is *surprised* that he has a large unpaid balance.

How he can say this with multiple invoices being emailed automatically and the multiple emails and phone calls trying to engage him is beyond me.  He now claims there was a spending cap on the project and says he ‘told me this’ early on.  Right, I would have agreed to two days on-site coding (after a months worth of offsite work) for him since those two days alone are higher than his supposed cap.

The funny thing is that after the project was done he still tried to engage me to do more work.  Unfortunately (or maybe fortunately depending upon your viewpoint) the hourly rate he wanted to pay was so low that I couldn’t have made payroll.

The lesson learned is never to do anything verbally when it comes to money.  At a minimum, after a video chat and/or phone call, send an email confirming the details.  The paper trail, while a pain to maintain, is the only way to cover your bases.

A contract is better, of course, because that’s a legally binding document.  The sad thing is that I presented on this very topic at multiple REAL World conferences so that means I obviously didn’t learn my own lesson.  But then I guess I was blinded by the connections this person has with Real Software (not that I hold them responsible) and the community.  The referral was from a trusted colleague too which made it ‘safe’.  When money is involved there is no trust.

As a word of warning, this person is trolling the forums looking for Web Edition coding help.  Make sure you get a signed contract from him before doing any work.  Get everything in writing, which, of course, is good advice for all business dealings.

Will I get what’s owed?  I sure hope so but somehow I doubt it.  Regardless, I’ve relearned a valuable (albeit costly) lesson.

REAL Studio Developer March/April 2011 Issue

REAL Studio Developer Issue 9.3 (March/April 2011) came out this week.  My column topic in this issue was the risks and rewards of being a consultant.

I don’t think being a REALbasic developer is any different than any other consultant.  There are times when you’re so flush with work you can’t sleep and there’s times you’re looking for work.  There’s always the ‘next project’ on the horizon.

Cash flow is just one of the many risks of being a consultant.  The rewards though, are nice when they happen.

Did I leave anything out in the column?  Something I should have talked about?

Task Timer for iOS

Task Timer for iOS

We’ve been very busy recently.  Besides all of our cross-platform desktop app consulting work we’re now iOS developers as well (feel free to contact me if you’re looking for iOS developers).  Our first iOS app, Task Timer for iOS, is now on the App Store.  This is the Lite, iAd supported version, of Task Timer, and simply lets you track your life and hopefully bill for it. This version works on the iPhone, iPad, and iPod touch.

Want to track how much time you spend commuting to and from your job?  Create a Personal project and add a Commuting task and the next time you get in your vehicle hit the start button and when you leave the car hit the stop button.  It doesn’t get much easier than that.

The same goes with your on-site with clients.  After the initial setup it’s as simple are pressing the start and stop buttons.  At the end of the day, week, or month, you can view a summary of all the time you’ve spent.

Task Timer supports multiple simultaneous timers for those multi-taskers out there that can bill multiple clients at the same time (yeah, I’m looking at you, lawyers).  The Lite version supports unlimited projects and tasks but does not sync to the desktop version.

What’s it worth to you to increase your billing by 30%?  Did I mention that the Lite version is FREE?

An upcoming (paid) version will be able to synchronize with the desktop version of Task Timer (for Mac OS X or Windows) all without being plugged in to your computer!  This will be a free upgrade for current owners of Task Timer for Mac OS X or Windows.

So never lose money again!  When we developed the desktop version years ago we saw an immediate 30% rise in billing!  Why?  Because we know, down to the minute, how much time we spend on a billable (and non-billable) projects.  It helps our bottom line with billing AND it helps us track how well we’ve done with our estimates.  If you’re not tracking your time you’re not doing a very good job at managing it!

We hope you enjoy this free version.

2009 REALbasic Consultants Survey

I almost forgot about this one in the rush to get the Colorado REALbasic Summit setup and announced.  ARBP is currently hosting its 2nd annual REALbasic Consultants Survey.  As we did in 2008, we’re asking REALbasic developers about their consulting business.  Also, we are now breaking out ARBP members versus non-ARBP members to see the differences and to help determine the ARBP demographics.

ARBP members should log into the ARBP Members site and click on the “2009 ARBP Consultant Survey” link under the ARBP Info menu.

Non-ARBP members can take the survey at http://www.surveymethods.com/EndUser.aspx?A185E9F5A2E6F0F6

Some of the preliminary results are interesting because in last years survey we didn’t stop the survey if you said you didn’t consider yourself a consultant and this led to a lot of answers about pricing and employees being skewed.  This year non self-declared consultants do not take a majority of the survey.  We also refined some of the questions to include more details.

If you haven’t already, I would appreciate it if you could take the survey.  The results help ARBP determine who our users are and in the long run it helps the RB consulting community by giving some baseline numbers for comparison.

Estimates and ‘The Reality Factor’

Estimates aren’t very easy.  In fact, I’d say that it’s the hardest part of being a consultant because of the time and effort that goes into making a decent estimate.  It’s really just an educated guess.

Think about it for a second.  You’re being asked to figure out how much time and money it will take do something without actually doing the work.  And in most cases a client has given you a vague, rough idea of what they want.  If you’re lucky.

If you’re unlucky, the client has an OPC (Other Peoples Code) project that they’re bringing to you to fix.  What’s even worse, they give you a paragraph of what the application does, with no specifics, and expect it to be done quickly and cheaply and correctly.

The other thing that sucks about estimates is knowing that we humans are notoriously bad at determining how much time something will take.  We’re good at estimating a lot of things but time estimates are ephemeral at best.  I started my career as an electrical engineering doing project engineering work.  It only took a few small projects (and getting chewed out when my estimates were horrible) to realize that my ‘it only takes a day to do that’ estimate turned into three days (or more).

So I have my multiply by three rule.  Take your estimate, which is really the ‘if everything works perfectly the first time and I can devote 100% of my day to it’ estimate and then multiply by your reality factor.

The real trick is learning from your past successes and mistakes.  Now that I have a standard tool set of classes, controls and modules that I’ve used on a dozens of projects it’s easy to say that adding ‘X’ is 15 minutes worth of work and the reality factor is 1.5.  Creating new controls, since it has a high degree of initial failure, might have a reality factor of 2 to 3.  If you have a feeling that a client is going to be really picky, maybe that reality factor goes up a little.  If the project requirement details are scarce the factor goes up again.

Trust your gut on this one folks.  The figure at the bottom of the spreadsheet seems high sometimes.  You’ll be tempted to lower some estimates to make it more palatable to the client.  Sometimes you might have to do that to get the job, but try to resist the temptation.  As a consultant your pricing is based on what your time and experience are worth along with all the other things that go into being a business.  You have overhead, marketing, taxes, insurance, and you have a retirement plan, right?

So what’s your Reality Factor?