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?

 

Xojo Consulting

When we (Christian Miller of Pariahware and myself) spoke at REAL World 2007 about Xojo (then Real Studio) consulting we had no idea what people wanted.  So we took the generic approach of  lets-throw-everything-we-can-think-of-and-fit-it-into-45-minute presentation.  We were surprised that nearly every seat in the room was filled.  We were off to a decent start.

To make a very long story short, we were pretty happy at the response to the presentation.  What surprised us even more was the Question and Answer session afterward.  There were a lot of really good questions.  One of those questions has come up again and again:  How do you find Xojo Consulting work?  It’s a good question.

In my opinion, the best way to find work is to get the Professional license for Xojo.  Yes, at $995 it is expensive but in addition to the Desktop, Web, Database Access and Console you get access to the Pro-only forum which includes access to Xojo consulting leads.  As a consultant I find myself using all the Pro features eventually so the price doesn’t concern me.  I do realize that not everyone has the same resources that I do.

There is a page on the Xojo website called Find a Consultant where potential clients enter basic details of who they are, how to contact them and a brief synopsis of their project.  That information is then posted in the Pro-Only forum.  In turn, the developers may contact the person who posted the project.

In my opinion, this is like shooting fish in a barrel.  The potential customer already knows (or at least thinks they know) that they want a Xojo developer.  So you don’t have to sell them on Xojo or the advantages of one code base for three platforms for desktop, web, and console apps.  Isn’t that half the battle?

I’ve been part of the program for a a long time (in all its various incarnations and price points).  The quality and quantity of the leads varies considerably but all it takes is one decent sized project to make up your investment. You can find more information about it at https://xojo.com/support/consultants.php.

Most of the clients I’ve obtained from these leads have come back for more work.  This doesn’t happen with every client, naturally, but it happens enough to make a note about it.  In several cases the original job was a small project so the client could see if we were worthy of the project they REALLY wanted to do.  These small projects are good to see if you and the client are compatible (people are people and some just don’t get along).

Other developers have had some luck with finding work on the hire a developer sites like Rent A Coder.  Some of these sites require a fee to bid on the listings.  I would use caution using these sites to find work as your competing against people from all over the world.  Some people can live on $15 an hour (or less).  If you can pay your bills and save for your retirement at that rate then go for it.  I know I can’t!

Bidding on a fixed bid projects is an art form.  I use some basic formulas that call for a certain number of hours for each window/class/control and for really complex windows or classes I break them out separately.  Then if you want to get an idea of how much time you’ll spend on a project multiply your estimate by three.  That will take care of interruptions and waiting for responses for questions, doing research, and all of the things you have to do on a project that you can’t directly bill for.  I know a few developers that use a factor of 5 in doing their estimates.

This might seem a bit excessive but nearly every project I’ve ever worked on (even as an engineer in a previous lifetime) this seems to work reasonably well.  This doesn’t mean that the bid is inflated by three, it just means that I’ve accounted for interruptions and other issues that come up that might cause a delay.  At any given time I’m usually working on three or four separate projects and each one needs attention on a regular basis.

Track the time you spend on each project.  If you can, track the time you spend on each part of the project.  After each project, review how long it took to do the entire project and if you can, track how much each portion of the project took.  After you’ve done it a few times, you’ll find out what takes more time than you anticipated and what takes less.  This is valuable feedback for when you’re first starting out and learning how to do things.

Another thing to keep in mind is that you need to live on what you’ve bid.  If your rate is $15 an hour and you live in New York City I doubt you’ll be living comfortably unless you have six roommates in a two bedroom apartment!  In the long run, what you earn has to take into account your lifestyle, your location, and your ability to set aside enough for your retirement years.

As a consultant if you can bill 30 hours per week that’s awesome!  Most consultants say 20 billable hours per week is good.  Use that as your basis for determining what you should charge.  You’ll need to allow time for dealing with administrative issues, taxes, writing proposals and looking for more work.  Then take into account vacation and sick time (it happens) and what your expenses are and you’ll need some padding because some months will be slower than others.

50 weeks * 20 hours = 1000 hours per year.  You determine that you can making a living if you bring in $80,000 per year.  That means that you need to charge $80 per hour.  $80,000/1000 hours = $80/hour.  Don’t forget that you’ll have to pay your own taxes and insurance so take those things into account!

To be honest we charge significantly more than the $80/hour rate.  This was just an example of how to do some simple math to come up with a consulting rate.  Hopefully your rate leaves you with enough to live on and start saving for retirement.

Where are you finding Xojo work?  Have any fun stories of a client saying no to your rate and then coming back a year later after spending far more than your original estimate?

Look for some posts next week about my experiences at XDC!

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?