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?

Debugging Your Xojo Applications

Your customers and clients expect your Xojo applications to be as bug free as possible.  What mechanisms do you have in place to handle an error and report it?  Bugs occur – that’s a fact of life – and even the best error handling in the world can’t prevent bugs from occurring.

Thoroughly testing your application is your first and best line of defense.  However, it’s very time consuming and without good testing procedures it may even be a waste of time.  I would also add the it’s very hard for the developer to be a good tester of their own code.  You programmed it to do a certain task in a certain way.  Someone else will have a different set of expectations.

Regression testing is the only way to really make sure that changes in one part of your code doesn’t change other parts of your application (or a new version of Xojo doesn’t affect you either!).  An excellent way to do regression testing on your software is to use the open source unit testing module called XojoUnit (it’s now part of Xojo).  It allows you to test your code with known inputs and test them against the actual output.

A common question from the forums is that people get an error message saying, “The application has encountered an error and must now shutdown,” and they have no idea what the error is or where the error happened.  They need to learn as much as they can about the Exception class and in particular the Stack property.  The stack was introduced way back in 2006 and is a string array that contains the methods that have run from the entry point into your code until where the exception occurred.  Be aware that the Include Function Names property has to be true in your application for the stack to be human readable.

Use the UnhandledException event in the application class to capture any errors that weren’t handled elsewhere.  The exception stack allows you to determine where the error occurred and from there it’s a simple matter to send an email, post to a web form or write the error out to a log file that includes important details such as platform, operating system version and the version of your application.

Some applications will require files be in a specific location and when debugging your application those files might not be in the proper (final) location.  Use the DebugBuild constant along with conditional compilation, #If,  to handle things differently at debug time and runtime.  For debugging purposes you can have the required files in the local project directory for convenience sake.  A feature added in 2007 allows you to place your debug build in a particular location which eliminates the need to have non-project files in your project directory.

Cross-platform applications require additional handling but now that Xojo with (or without) a desktop license can do remote debugging and it’s very easy to do.  I run the Xojo IDE on Mac OS X on an iMac and use VMWare running various versions of Windows and Linux so I can debug my applications in those environments.  The remote debugger works exactly like the regular debugger except that the debug application is running in another environment.  It’s a little slower to initiate since the app has to be transferred to the other environment but otherwise it’s the same process.

I highly recommend testing early and often on the other platforms you’re developing for.  Don’t wait until the end to do extensive testing.  While Xojo does a great job on cross-platform applications there ARE platform differences you need to be aware of.

New developers coming from Visual Basic 6 are often irritated by the perceived lack of database error in Xojo.  An incorrect SQL statement when opening a recordset results in nil recordset objects instead of a throwing a runtime error.  The unexpected nil recordset then causes NilObjectException errors.  You must get in the habit of checking your database object for errors after every database operation.  Once you catch the error you can at least be more graceful on how to recover from it.

That’s a lot of information so do your research.  Debugging your application isn’t as hard as you think.

What things do you do to make your life easier hunting down or preventing bugs?

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!

 

New Web App Training Series

BKeeney Software is proud to announce a new 4 1/2 hour video training series for subscribers at http://xojo.bkeeney.com/XojoTraining/.  The new LinkShare Web App series takes budding Xojo developers from nothing, to a fully functional web application.  This eight part series is designed to familiarize the beginning and intermediate developer on how Xojo web applications are created and how to create the basic infrastructure required for most modern web applications.

Just a few of the topics covered:
• Project organization
• Database integration using ActiveRecord and ARGen
• Safe password handling, storage and login procedures
• Sending emails and how to communicate with the app via URL parameters
• Basic WebStyles
• Basic WebPage, WebDialog and UI layout and interaction
• Much, much more

The series comes with source code the Xojo developer can use in their own projects.

BKeeney Software has 183 separate videos, with over 52 hours of Xojo and Real Studio training video and source code at http://xojo.bkeeney.com/XojoTraining/.  The site is a Xojo web app and has served up over 7,750 hours of streaming video to thousands of developers since it went live.

More information at http://xojo.bkeeney.com/XojoTraining/ or contact Bob Keeney at support at bkeeney dot com.

ARGen Version 1.6

ARGen256Today we released an update to ARGen, our utility to create ActiveRecord classes for your Xojo and Real Studio database projects. ARGen costs a mere $19.95 and can save you many hours of tedious and error-prone database coding.

ActiveRecord for Xojo does a number of things for you. First, it eliminates much (not all) of the SQL required to work with your database. Second, it lets the IDE autocomplete work for you using Table.Field notation as well as letting the compiler warn you when you are doing an illegal datatype conversion. Lastly, ActiveRecord will throw an exception if a field is missing from the AR classes (debug only).

Version 1.6 is a free update to all users of ARGen. The demo version allows you to output two AR classes at a time.

New in version 1.6:

  • ARGen now outputs the entire ActiveRecord class structure so you no longer have to download the ActiveRecord package from our website to add it to your project.
  • Outputs only for the database you’ve selected
  • Restructured the OpenDB a bit to include the table registration

Download and more info at http://www.bkeeney.com/allproducts/argen/ 

 

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?

Thoughts on Xojo Web Edition

When Web Edition for Xojo (then Real Studio) was released I can’t say I was overly impressed.  It was missing some features and was buggy (to put it mildly).  I was of the opinion that it just wouldn’t take off.

Since then the worst of the bugs were fixed and the worst of the framework problems were addressed and there’s been a steady improvement in the product in practically every release.  In my consulting business it’s went from being a ‘gee that’s a nice thing to have’ to being roughly half of our overall Xojo consulting business.

The fact that we had very little web development experience hasn’t stopped us from using Xojo for a lot of projects.  It’s great that a WebButton and a regular desktop Button and that a WebPage and Window act the same from a developer standpoint.  All the code experience that we learned over the course of a decade in desktop apps was, with a few notable exceptions (*cough* constructors *cough*), was immediately transferrable to web apps.  While there is a learning curve it’s not like we had to learn a completely new programming language to do some large and complex web apps.  In fact, we turned down work before Web Edition came out simply because we didn’t have the experience and in-house know how to do the work.

Our clients seem willing to forgo the numerous capabilities and power of a desktop app for the more limited capabilities of a browser based app.  I think the biggest reason being that web apps don’t have distribution issues.  There’s only one instance of the app sitting on a server somewhere.  Web apps also work in almost every desktop browser and even work with most mobile web browsers.  Heck, you can even configure the web app to look different based upon what device it’s being viewed on.

There are some disadvantages, of course, to Xojo web apps.  You can’t just put them up on any ol’ server.  You pretty much need a VPS or use the new Xojo Cloud (which is just a specially configured VPS).  Then you have to worry about 32-bit compatibility libraries but, honestly, once you get the first app running on a server the rest of them are pretty easy.  I’ve not had the pleasure of getting a Xojo web app working on IIS but I hear it’s not a pleasure, nor quick, experience.

Apps running in a web browser have a limited subset of capabilities. With Xojo web apps you can’t use drag and drop anywhere out of the box (I think you can do some of this with JQuery but I’ve not tried yet).  The controls, particularly the WebListBox, are lacking a lot of functionality, and there’s just not a wealth of 3rd party controls available for Web Edition yet.

Security-wise, Xojo web apps are compiled making it very hard to compromise an app even if a hacker gets into your server.  There’s still work to make your app secure from SQL injection attacks but that’s a relatively simple thing.  Much of the work is really securing your server so that it’s secure and that’s one thing that Xojo Cloud is doing well (perhaps too well based on my recent experience).

So the question, Dear Readers, is what are your biggest likes and dislikes about Xojo Web Edition?  What do you wish it did better or differently?

JavaScript Error (or Banging Your Head Up Against a Wall)

In one of our big Web Edition projects I recently added a new dynamic WebContainer option to the home screen.  It generated a JavaScript error on occasion but because it was under active development I wasn’t too worried about it.  Sometimes those errors fix themselves given some time.

I figured that I was doing something to a control before it was being shown.  I went round and round with the bug adding timers to add delays and changing the order of when things were shown.  It was really bugging me and I even contacted Xojo support because it was happening on the Xojo Cloud server during the alpha period but yet I was seeing different behavior on my VPS host.

Eventually, we really looked at the javascript error:

document.getElementById(‘EK7iZlsZ’).style.overflow = ‘hidden’;

If you go into the Web Inspector in Safari and in the console paste in document.getElementById(‘EK7iZlsZ’) it resolves to a Style.  It was confusing because that style is used everywhere and all styles are static meaning that I’m not replacing or changing that style on any control, anywhere in the project.  We all assumed it was an order issue with the web framework.

The bit that finally tipped us off to what the real problem was the ‘style.overflow’ part of the JavaScript error.  That is NOT visibility of a control, that’s the JavaScript for ScrollbarsVisible and it’s a property on all WebContainers.  This is the property that will let you change how scrollbars work on the WebContainer.

Of course, once we knew what the error was it was trivial to change it.  The line of code I had in an initialization routine of the WebContainer was self.ScrollbarsVisible = 2.  As soon as I moved this to the shown event the problem went away.

If you are a heavy user of WebContainers this might bite you at some point in the future.  Perhaps you’ll remember this blog post and remember how you thought Bob was a silly old programmer for missing something so obvious.  :)

Gotta love hours and hours of work for moving one line of code.  Of course, along the way things got more efficient and I removed a bunch of time delay code that was no longer needed.  I love programming some days.  Now to repair the dent in wall from banging my head….

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?