What About Bob?

A number of recent forum threads and blog posts have invoked my name.  I mostly didn’t respond to those individual posts and decided to write one big post.

I’m still in the community:  Sort of.  I took a full-time job just before the pandemic hit the US and I’m so thankful that I’m able to provide for my family in a stable and hopefully long-term position.  Xojo consulting wasn’t keeping me very active and that’s even after it was just me doing the Xojo consulting.  You can chalk this up to a variety of issues that all revolve around Xojo.

Consulting leads just don’t show up like they used to:  At the height of BKS we had 4 full-time developers and a DBA/Project manager.  That means we picked up at least two big projects a year and a ton of smaller filler projects.  Those just don’t show up any more.  Do cross-platform apps now use a different language?  Is it because of Xojo quality issues?  Is it because of bad press?  Is it because I expressed my displeasure with Xojo?  A global pandemic that greatly accelerated a looming recession? Sure.  All of the above probably.  But I know other consultants that are in the same boat though a select few have flourished during this period too.  So maybe it’s an ebb and flow thing.

The whole API 2 fiasco:  API 2 is of dubious quality for existing projects.  If you have a couple hundred thousands of lines of code in classic API code you simply do not have the time or resources to convert.  What’s worse, is that I have several Windows apps that crash (as in poof!  No crash log or catchable exception) in any version of Xojo that uses API 2.  This one thing keeps me using 2019 R1.1.  (Update, this was resolved in one app that used WebKit for the HTMLViewer renderer and is marked as fixed for 2020 R1.1).

If you want proof of this statement ask anyone at Xojo when the entire IDE is going to be converted to API 2.  That alone is a multi-year project and I don’t care what Geoff says – they are NOT eating their own dog food when it comes to API 2.  They decided that it wasn’t worth converting to API 2 for existing work.  That says volumes if you ask me.

More targets less engineers:  Xojo used to have only desktop targets which meant that everyone on the development team focused on desktop.  Since then they’ve lost/fired engineers and created more targets.  How much time and effort has gone into iOS, and now Android development?  You simply cannot tell me that they are adequately staffed to handle all of these targets.  Web has been a multi-year project as has Android.  In the meantime they touched every single class in Xojo for API 2.0 and given the results I’m not sure the platform as a whole is better for it.  As far as I know they have no *dedicated* compiler engineer and that seems to be an issue with 64-bit debugging.

Locking of threads and banning of users on the forums:  It’s their sandbox and their tools so they can do whatever they want with their forum.  But it sure seems like a lot of threads get locked (by non-Xojo employees!) and posts get deleted rather quickly.  Look, I get it, they want to present a consistent look to the world but the almost fanatical control of the forum feels…desperate. Banning of users should be the very last resort.

The comical stance that professional developers are not the core users of Xojo:  Xojo will deny this, of course, but I’ve been around for 20 years in this community.  I’ve seen a lot of developers come and go.  There’s the hey, this product is very cool phase.  Then there’s the now I’m going to do something hard with this tool phase.  Some get through it.  Many don’t.  With the many dealings with former Xojo users not once have I heard of Xojo contacting them on why they left.  

Hell, maybe the users that know Xojo the best are the hardest ones to please.  Maybe it *is* easier to find new buyers than to appease existing customers for renewals.  But it’s the existing users that are the best marketing tool of the company in my opinion.  How many times have I promoted Xojo over the past 20 years?  Many people accused me of working for Xojo and being a shill.

Trust is Earned:  One of the things that we, as developers, need is trust in our tool of choice.  For many developers that have been around a long time that trust was earned a decade ago.  The API 2 fiasco and the many new targets has eroded and downright sheared off the goodwill for many of Xojo’s most ardent supporters.  I don’t know how the company recovers from those hits without being brutally honest with users and themselves.  They simply cannot be everything to everybody.  With Swift getting ported to Windows and .NET Maui on the horizon, in addition to other tools that are making big strides in cross-platform development Xojo needs to be laser focused on quality releases or they might find themselves in the dustbin of history.  Earn back our trust and I think they’ll be rewarded.  Keep mucking around with the above issues and the future doesn’t look bright.  Again, in my opinion.

Where I’m at:  I’m still doing Xojo programming for a living.  I am not doing much consulting because I don’t desire to.  I’ve always tried to do the best for my clients and, frankly, Xojo is not living up to my expectations for my clients.  I think they’ve forgotten where they came from and what developers LOVED about the product.  I’m sure there are some people that find Xojo because of web apps or iOS but I can’t imagine it’s a lot of new users.  I could be wrong on that but I’ve wondered for many years who is Xojo’s audience.

My products, the ones I’m still selling, are getting minimal to no effort on my part simply because I’m not doing much consulting.  These products were things I used on a regular basis and with no consulting there’s no usage and no need to update.  I’m looking for homes for them because they deserve to have a developer that cares about them.  Some in the community have suggested open sourcing them and I can tell you right now there is no freaking way that’s going to happen.  No argument in the world is going to convince me otherwise so just stop sending me that recommendation.  I’m not asking for much (in my opinion) to get these products but perhaps that’s also indicative of how poor the Xojo 3rd party market is right now and an overall indicator of the health of Xojo.

I wish nothing but the best for Xojo.  This last year and half has soured my outlook to the point where I just can’t recommend it to anyone that’s serious about a commercial desktop applications.  I haven’t done a web project in well over a year and it’s been many years since I’ve done an iOS project in Xojo.  Without outstanding desktop support I’m left in limbo and wondering why the hell I keep renewing a license.

I know I’m not the only one with these thoughts and ideas.  Feel free to add comments below.  Please try to be respectful towards Xojo employees and each other.

AutoComplete Wish

I understand that the future of Xojo is API 2.0.  I have used API 2.0 and while I disagree with some of the naming conventions I can live with it.  I do have a problem with many of my older projects, however.  My older projects, especially the big ones, will most likely never use API 2.0 because it’s simply too big of a task to convert.

To upgrade to API 2.0 for a desktop project I have to change my error handling to go from checking for error codes to handling exceptions.  Any string manipulation cannot simply be upgraded because the older API is 1-based and the newer one is 0-based.  And the sheer number of property name changes is disastrous in some projects.  Converting from Date to DateTime is not a simple replacement either.

That’s not to say that these things are not doable but they are not desirable right now.  And I’d really like to not accidentally invoke an API 2.0 method or property because AutoComplete shows me both.  AutoComplete conveniently shows me the old, classic property/method in red which is great but I have no way of knowing what is new for API 2.0.  Therefor I’d love to have the option to choose what is shown in AutoComplete.

Feedback 57885 Feedback #57885 is just that.  This case is currently ranked fairly high so I’m not the only one that thinks this is a great idea.  The basic gist of it is this:  there is a preference setting that allows me to select what I see in AutoComplete, API 2.0, API 2.0 and Classic, or just Classic API.

In the ideal world (as stated in the Feedback case) this would change the deprecation warnings for API 2.0 if you’ve selected Classic API and it would also switch the local documentation to the proper usage to avoid confusion.

Obviously, Xojo does NOT want to implement this because API 2.0 is the future of the platform.  My argument is that without this mechanism many of us with older, big projects, won’t update our licenses because we can’t/won’t use Xojo with API 2.0.  

This is not a good situation to be in because I feel we’re one macOS upgrade away from disaster.  If you’ll recall before Catalina was released FolderItems were broken in  for a while.  This turned out to be an Apple bug that was fixed.  Another example is the ColorPicker and if you’re using an older version of Xojo you have issues with it that you have to workaround.  What happens with Son of Catalina comes out and something else is deprecated and we *have to* upgrade to newer Xojo.

You might feel like I’m complaining for the sake of complaining.  I assure you I am just looking out for my clients assets and my own hard work.  I can’t justify the cost and expense to upgrade to API 2.0 and I really don’t want to mix and match API’s.  I could use a newer version of Xojo but I just can’t take the chance of using something (API 2.0) that’s not fully proven (to me) yet.  All it takes is one mistake and I have a mad client.

Currently 57885 is ranked 9th.  If you’d like to see it get implement throw your points at it.  What do you think?  Am I agonizing over AutoComplete too much or do you think I’m justified in my concern and request?

May We Live in Interesting Times

I’ve been a Xojo consultant for nearly 20 years.  BKeeney Software has worked on dozens of commercial applications and untold numbers of private projects during that time period.  Consulting is both an extremely rewarding and terrifying business since income can be so variable.  We’ve had multiple employees for years and providing health insurance costs is an expense that’s ever growing.  Having your own business is hard in the best of times.

Over the past twelve months we’ve had two employees leave on their own volition to pursue other employment opportunities.  During that same period the amount of new projects slowed to a trickle and even existing clients haven’t brought in as much new work as they have in the past.  Where once we routinely acquired new projects it just didn’t happen as much in 2019.

Consulting is a weird business where every client wants their project done last week for as little money as possible and then get yelled at when you tell them version 2 is going to cost a lot more money.  As a consultant I’ve had to compromise with what’s best for a project with what the client is wiling to pay for.  It’s a constant struggle and one that I can’t imagine going away as a consultant.  

Earlier this year I was presented with the opportunity to take a full-time job as a senior developer for a company that uses Xojo along with other programming technologies.  I have accepted that position and started with them in a full-time capacity a few weeks ago.

BKeeney Software will continue to support existing clients to the best of our ability.  We will not be taking on new clients and we will have to be very selective in taking on additional work.  We hope the transition is as painless as possible.  When we cannot do the work we will give clients a list of Xojo consultants to contact and we will coordinate with them as best we can. If you’d like to be on that list let me know. Send me an email with your qualifications, types of projects that are in your wheelhouse, and maybe even a client reference I can contact.

Several Xojo developers that know me socially (and knew about the new job) have asked about our products, mainly ARGen, Shorts, and Formatted Text Control.  At this point in time we will continue to offer support just like we always have.  However, we are hoping to find new homes for them and have already reached out to various developers that we feel will treat them and our existing customers right.  Our products were mostly driven by consulting and if we are not consulting we have no need for the products.  Since we know a lot of developers use these products we’d love for them to stay in the community and stay actively developed.  If you are interested in acquiring the rights to any of the products, please contact us.  

I love the Xojo community and its users.  I’ve never found a community that is as passionate about a product as the readers of this blog.  I’m not leaving the community – but transitioning into another form.  My new job uses Xojo. It’s a very large project and is certainly bigger than anything I’ve ever worked on before.

I’m looking forward to working on a set of products with a team of dedicated developers that are working on products that matter while providing a stable work environment for my family.  Certainly the events currently happening in the world do not make consulting any more stable so the timing of this opportunity was exceptionally favorable.

I still plan on doing some blogging about Xojo but it will certainly slow down.  As Web 2.0 and Android hits I will kick the tires and give my opinions of them because…well…I always have an opinion.  🙂

Stay safe and I look forward to seeing you all again at a Xojo event! Happy Xojo coding!

Chasing Unicorns

I’ve been on the search, recently, for alternatives to Xojo.  I’ve done some basic research into Lazarus and RAD Studio and both came up short in a variety of ways that you can read about in past posts.  So what am I looking for in cross-platform development tool?  I’ll spend the rest of this post talking about some of my requirements.  

Desktop Targets

Most of our consulting work is macOS and Windows with the occasional Linux or Raspberry Pi project thrown in for good measure.  Whatever development tool I choose it needs to be able to build for Mac and Windows at a minimum and anything it can do with Linux is an added bonus.  Rarely do we get a project that is just Windows or just MacOS.  Being able to desktop and consoles apps is a must on each target platforms.  

Native Controls

Maybe it’s my Mac background but I’d like my controls to be as native as possible.  This means that when Apple, Microsoft, or Linux distribution changes their UI (again) the application will just work without requiring an update from the vendor.  I’ll be honest that this is a want-to-have option as even Xojo isn’t completely 100% native (Listbox I’m looking at you).  Accessibility is a big concern for some clients so I’m willing to forego native if it’s ‘close enough’ and works.

Mac IDE

I’m a Mac user so I’d like to stick to my platform of choice if I can.  This means that the IDE must have the features that I come to expect on the Mac (keyboard shortcuts, standard Mac text editor features, Finder integration, and so on).  Can I live with working in Windows?  Sure, but remember I’m searching for unicorns so it’s not my first choice.  Plus, having a Mac IDE is a good indication how good of a cross-platform development tool it is.  I find it laughable, really, that some companies create cross-platform applications but yet don’t have a Mac IDE.  Um…so do you *really* do Mac applications or is this a marketing checkbox?

RAD Environment

I’ve been doing Rapid Application Development using Xojo for nearly 20 years and while you could argue that parts of Xojo are not very RAD (database development I’m looking at you) it is very easy and simple to get simple applications developed in practically no time.  Just last week I was able to get a simple Mac/Win desktop application developed for a client in four hours and that included preferences, full menubar, a simple text editor, talking to a web API, all with code signing, notarization, and installers.  Some of that is experience and the kit that I’ve developed over twenty years but some of that is simply Xojo.  Xojo makes it easy to create a MenuBar and quickly create menu handlers at either the application or window level.  The integrated Layout Editor makes it easy to add events for the window and controls and automatically drops into the integrated Code Editor.  I really want the next development tool I choose to be as easy to use as Xojo so I can get work done quickly and efficiently.

As a bonus I’d like my IDE to have integrated git and/or subversion integration.  I’d also like built-in code signing and notarization if possible too.  I realize this last part might require some remote magic since only a Mac can code sign and notarize Mac applications.  Neither of these options are available in Xojo at this point and require command like voodoo or a third party utility.

Double-Clickable, Compiled Executables

I really need my apps to be double-clickable in the Finder and Windows Explorer and just run.  I should never have to start up an application with the command line nor should I have to have a runtime installed to run the application.  Xojo applications are packaged to run independently and on the Mac they are in a bundle and even in Windows and Linux they are self-contained builds not requiring anything special from the operating system (as in no runtime necessary).

Community Size and Friendliness

I’d like my new development community to large and friendly.  When I have those inevitable questions regarding my new language and IDE I want a lot of options and where the community isn’t full of jerks.  For all of its issues this is where Xojo really shines because it’s one of the most helpful and friendliest communities I’ve ever been part of.  I’ve seen the vitriol spewed in other communities when newbies ask a question that should probably be obvious.  Hey, mistakes happen, and what’s obvious to one person may not be obvious to another.

Consulting Community

I’ve spent the last two decades as a consultant so why would I stop now?  Whatever community I go to I’d like there to be a decent consulting community where an up and coming developer could make a name for themselves.  I have no problem becoming ‘certified’ (whatever that means) to get listed and to get prospective clients.

Large 3rd Party Ecosystem

One complaint I’ve had about Xojo over the years is the lack of 3rd party options for controls and libraries.  If you want reporting options, a better grid, PDF creation and viewing, database ORM options, and a whole host of other controls and libraries your options are extremely limited.  My new development tool should have a vibrant 3rd party community so I don’t have to reinvent the wheel in many projects.  I’m okay paying money for a quality controls and libraries but what I really want are options because each one is different.

Good Documentation and Examples

This seems pretty self explanatory.  The documentation should be sufficient to learn the language.  In an ideal world it would be fully fleshed out so you can get a feel for the gotchas.  As far as examples go they should just work without having to futz around fixing stuff.

Bonus Things

It can do web apps.

It can do iOS and Android mobile apps (with some of the same caveats above).

The company/community behind it has a roadmap and what they want the language and IDE to be in the long run.

A standards organization behind the language.

A large enough company behind it, or a large enough community, to ensure future new features and timely bug fixes.

The things that I’m NOT concerned (much) about

Pricing – if it works then the price is (almost) irrelevant.

Licensing – if the language, IDE, and controls and libraries let me create commercial applications then I don’t care if it’s an MIT, GPL, LGPL, or Commercial license.

So that’s my unicorn list.  If Xojo is not going to be my long-term development tool these are the things I’m looking for.  Is this an impossible list?  I don’t think so but as someone coming FROM Xojo these are the things I’m looking for.  I you have some suggestions, I’d like to hear them and please let me know what the tool does NOT have from my list above.  I know it’s highly subjective but I think it’s important to acknowledge the limitations of the language and tool you work with every day.  Like Xojo, no development tool is perfect.

I’m Not Xojo’s Target Audience. Is Anyone?

I took the time out of my schedule to reach out to Xojo this week to discuss the issues I have with API 2.0 and other topics.  It was a fruitful, if somewhat disappointing, conversation with Geoff.  Like Anthony from Graffiti Suite I am cautiously optimistic that some of the worst issues third party developers have with API 2.0 might be alleviated.  Really we won’t know until we see their solution

One of the topics that I brought up was that these issues (the new Event names and marking anything from API 1.0 Deprecated – even though they’ll be around for a many years to come) were brought up early and often in the beta program.  I said that honestly, it made us feel that our input is not valued.  Geoff’s response is that the beta testers that brought these issues up is a small subset of the overall beta program and what they (Xojo) didn’t realize was those beta testers have other Xojo developers behind them (other Xojo developers) that aren’t in the beta program.  They assumed that most of our users were using the most recent version of Xojo.

So, in other words, the biggest, most active users of their development tool, that are in the beta program because they want to be and need Xojo to work because of THEIR clients, their concerns could be ignored.  It means the professional Xojo users aren’t considered a part of their target audience.

Wow.  That is stunning to tell someone that has been in the beta program for (probably) over fifteen years that their input doesn’t matter.  The three pro licenses that I’ve been purchasing year after year for over a dozen years doesn’t matter.  The many years of blog posts promoting the product don’t matter.  The thousands of hours of streaming video training about the product don’t matter.  

I’ve been going to Xojo Developers Conference (XDC) for years.  I’ve spoken at all of them since 2004.  The conferences are expensive enough to attend that really it’s only the professional users that attend.  There are some citizen developers that attend but mostly it is people that make a living off of using Xojo in some way.  Maybe this is why XDC is now being marketed as Xojo.Connect? Targeted for citizen developers?  I don’t know but it’s not any less expensive.

I asked Geoff if they’ve ever asked why long-term users stopped renewing.  The answer was no.  They did it years ago with people that signed up to download Xojo but never purchased.  They couldn’t find a pattern which I totally get.  Heck, I’ve downloaded and discarded dozens of development tools over the years just to kick their tires.  But not knowing why someone stopped paying you $700 year after year?  Seems like it would be an important thing to know.

I’ve been around a long time and have remained friends with some of those former Xojo developers.  Some leave because of long-term bugs.  It is disheartening to report a bug that affects your app that gets ignored for years on end.  Granted not all bugs are equal but a show-stopper bug is just that.  When your bug is ignored it’s pretty easy to check out.

Some leave because Xojo isn’t as RAD (Rapid Application Development) as it is billed as.  Database driven applications (which I would say is what most businesses need) is pretty bad (hence why we’ve had our own library forever).  Why use Xojo if it’s not RAD?  

Some leave because there is a lack of capabilities in the product.  iOS (but also true for all targets) is painfully lacking in capabilities that force you into learning complex declares.  There are no built-in controls for Date, Time, Timestamp, or numbers only Text Fields, exporting to PDF, no ability for applications to have a report editor, a good grid, etc.  Some of this is because Xojo is the lowest common denominator between Mac, Windows, and Linux (for desktop) and doing these things cross-platform is really hard.  

Some leave because of the lack of options.  Xojo has a tiny 3rd party add-on market.  You only have a few options (if any) for some things or you make them yourself.  Users hate reinventing the wheel.  Xojo itself doesn’t do much to promote or help the 3rd party market.  Other development tools have significantly more options to choose from.

Regardless, there are probably a ton of reasons why people leave.  I suspect that most come down to some variation of the above.  These are also the same reasons why new users will walk away too.

Citizen developers can walk away from Xojo with hardly a second thought.  They’ve invested practically nothing in the tool.  When you’ve been in the Xojo ecosystem for many years apparently we’re taken for granted because the cost of moving is so high.  But who are the cheerleaders for the product?  Who helps new users in the forums?  The less active the community the harder it’s going to be to get those new citizen developer sales.  I see this as a negative feedback loop.

I’ve been a Xojo consultant for over over sixteen years.  I guess I’m not their target audience.  Is anyone?

Task Timer 6

We are pleased to announce the newest version of Task Timer. It has been four years since our last update to Task Timer, so we’ve started from the ground up. Task Timer 6 is faster than ever before and ready for the future!

Never lose money again! Track your time accurately with Task Timer. Get back lost time by knowing how much time was spent on any project. Use historical time tracking data to improve your estimates. Never again find yourself guessing at billing.

Projects and timers are now easier to manage, start, and stop. Managing time sessions is now faster and easier to do. The events manager no longer blocks the main window, and we fixed a couple bugs along the way.

Version 6 will automatically import and convert all existing Task Timer 5 data. You won’t miss a beat. Stop all timers in Task Timer 5 and close Task Timer 5. Then simply open Task Timer 6 and import.

Task Timer 6 is a crucial update. Unfortunately, the previous version is near it’s lifecycle end by more than one cause. We regret that we will be unable to support Task Timer 5 in any way due to the final closure of the commercial licensing server we were using.

To encourage everyone to upgrade, the Task Timer 6 software will automatically offer an upgrade discount. If there are any troubles with the automatic process, please don’t hesitate to contact us at support@bkeeney.com!

Download Task Timer 6 today! https://bkeeney.com/tasktimer

Evaluating Prospective Xojo Clients

A couple of weeks ago I did a blog post about evaluating Xojo consultants.  I think if you’re hiring a Xojo developer the consultant should clearly be an expert in Xojo and should be able to publicly show why they deserve your hard earned money.  But, there are two sides to the equation and I didn’t talk about evaluating the prospective client.  Here are some of the things that are red flags to us and maybe why we should steer clear of them.

Does the prospective client have a clear idea of what they want?  We’ve had clients that had a mere paragraph of content but could clearly articulate what they wanted.  Other clients have written an 80 page document full of meaningless gibberish that required a three hour face-to-face meeting to understand it.  

This is hard to evaluate but I’ve learned that if I can’t understand what the client wants and needs within a reasonable amount of time we’re not a good fit.  Either they can’t articulate what they want or it means that we’re just having communications issues.  It’s also possible they don’t know what they want and they want us to figure it out for them (which is a completely different project).

Has the prospective client worked with other Xojo developers before and been unhappy with the work?  Don’t get me wrong, we’ve picked up a lot of happy long-term clients and projects this way.  The client worked with another Xojo developer that couldn’t finish the project for a variety of reasons (like going back to a corporate job, or they bid too low and couldn’t live on the resulting income).

This is hard to evaluate too and you have to take it on a case by case basis.  Listen for the reasons why they were unhappy with the consultant.  Do their reasons seem petty or legitimate?  Do they accept at least some of the responsibility or do they put it all on the consultant?  Reasonable clients will accept partial responsibility.  The unreasonable clients, and the ones to stay away from, blame everything on the consultant.

The prospective client thinks they can do some of the work.  They have experience in <x> language and want to implement some of the work in Xojo on their own.  Or they feel their proof of concept project written in <x> language should give you a huge leg up on the overall project.

As with the previous points this is hard to evaluate.  Xojo is an easy to learn language but it’s been my experience that making Xojo work like <x> language is a recipe for disaster.  Xojo is Xojo and not like java or FileMaker or anything other language or environment.  Maybe their work helps but mostly it probably won’t.  It’s just easier to assume it’s going to be a complete rewrite.

The flip side to this is there are some clients that really are competent developers – just not in Xojo.  We’ve done a number of projects where we start the project for them.  We complete the basic infrastructure and give them some example List and Edit forms whatever else they want help with and then turn it over to them to complete the rest of the project.  They usually come back with some questions but for the most part they finish it themselves.  I consider this as part consulting and part training and we put more comments into code so they can understand the code better (since they’re learning).

The prospective client is always fighting with you about money.  We’ve had clients that want estimates on features so they can get their project done as cheap as possible.  I don’t begrudge any client that wants estimates on features to save money, but there are those clients that always complain about every penny and fight you on estimates and change orders and demand proof for every little thing.  They also tend to hold you to the dollar on any estimate you give them.

We had one prospective client that came with a project written by another developer.  It was referred to us by a Xojo consultant leaving the industry and couldn’t help them.  The project had a silly design where the SQL query was a staggering 200 pages when copied into a text editor.  It literally took minutes just to create the query and many minutes for the database to return results.  The only way to really clean it up and make it work properly was to break it up into smaller queries.  It would have given them more flexibility and it would actually speed up their entire process rather than locking the app up for minutes at a time.

Regardless, we came up with the estimate to fix it.  They said it was too much money and we parted ways.  They came back again in six months when the Xojo developer they found to ‘fix’ the query couldn’t do it (because it really needed to be broken up into smaller queries) and we gave them the same estimate.  It was still too high for them.  Six months later they came back yet again and asked if the price was the same.  It was not because we had raised our base rates.  We’ve never heard back from them and I wonder if they’re still in business.

Many clients are a delight to work with.  Not all of them will be long term clients but some will.  If you don’t get a warm fuzzy feeling after communicating with the client a few times you should really figure out why.  You’re going to know their project better than they do so you’d better figure it out before starting a big project.

Ironically some of our longest term clients were hard to work with at first.  See, they had bad experiences with other developers and were wary of being burned again.  Keep that in mind too. They’re being hard on you because they weren’t with their last developer.

These are just a few of the red flags that should concern you when talking with prospective clients.  What red flags do you look for?

Evaluating A Xojo Consultant

We had an interesting conversation with a prospective client last week.  Well, I should back up and say this isn’t the first time we talked to them as we were a finalist for a project of theirs two years ago.  Turns out their Xojo consultant is having a hard time completing the work and not giving them deliverables in a timely manner.  This is for a project we estimated at less than six months worth of work.

The client is looking for someone that could come in and complete the project for them.  They were hoping that a large majority of the work could be reused.  My response was that this was unlikely for several reasons.  The first being that they used their own kit which means a set of classes, subclasses, and libraries that we are unfamiliar with and for me to use them without serious investigation (i.e. time and money) would be less than ideal.  Plus, if I’m the developer for the project I’m now responsible for it working and I’m taking a gamble on code that I don’t know and haven’t vetted.  

My second thought was wondering if their overall design had been the cause for some of the delay.  Perhaps they coded themselves into a corner.  It’s an awkward conversation to have with a client – especially after they’ve spent a boatload of money.

Regardless, I’m sure our conversation was not what the client was looking for.  They wanted a project savior because their consultants had deceived them in their capabilities and in their ability to deliver.  

We politely asked who their consultant was and they told us.  A brief internet search pulled up the company website and their *one* Xojo related post.  Everything else on their website is hardware and .NET related.  If I was evaluating a Xojo consultant that would give me some pause for concern.  You really want a consultant that does a lot of Xojo projects.  Xojo is not like .NET or Java or any other language.  It has its own set of strengths and weaknesses (just like every other language) and I’ve seen it all too often where a developer tries to make Xojo do what <insert language here> does.  It’s almost always a disaster.

We’ve been using Xojo for over 16 years.  If I’m not friends with most of the Xojo consultants out there I at least know of them and their reputation.  I have lost bids to my competitors and if the prospective client will tell us who they chose I can at least give a thumbs up to those that I know and trust since I know the client will be in good hands.  For those that I don’t know I don’t give any opinion.  But it’s also been my experience that those consultants that stick around are good and are active in the community.

If you’re hiring a Xojo consultant you should always ask for references.  If you’re going to spend tens of thousands of dollars (or more) with them you should do a little homework.  Don’t buy their assurances.  If they are really reliable then they will find references for you to check out.  This will let you know if they do good work, are on time, and on budget.  Are they reliable?  Are they hard to work with?

If you’re new to Xojo consulting that’s okay too – we were all new once.  Be honest with the client and do your best to prove to them that you’re up to the challenge.  

The Xojo community is very accepting and the forum is filled with developers that have provided answers to newbies, provided source code examples, and even established public repositories to share their code.  Have they spoke at any Xojo developers conferences?  Written for Xojo Developer magazine?  This public work can, and should be, part of the reference list.  This shows the prospective client that you really know and work with Xojo.

Hiring a Xojo consultant isn’t that difficult.  There are a number of qualified consultants that will create a great project for you.  The first step is to fill out the form at Find a Developer page on the Xojo website at https://www.xojo.com/resources/consultants.php.  This will get your project in front of everyone looking for work.  Then it’s up to you.

Ask about their Xojo work they’ve done in the public.  Ask for their references.  Heck, ask them what they love and hate about Xojo (that might be a long conversation).  If you don’t do your homework you might be wasting an opportunity in not getting your project to market, or waste tends of thousands of dollars for work that doesn’t get delivered.

BKS Report Studio

Connect to a Myriad of Databases without writing SQL: BKeeney Software Launches New, Cross-Platform Reporting Tool

###

LENEXA, KS, 20 September 2018 – BKeeney Software launches BKS Report Studio, a simple database reporting tool that features a visual interface, templates, and editing features that allow users to create reports without writing SQL.

Designed for every skill level, BKS Report Studio operates like a layout editor by allowing users to drag and drop data sources, labels, images, and even barcodes to build powerful reports, quickly.

Reports can be printed directly, or can be exported in several file formats. Created by a need to simplify and extend the database reporting process, BKS Report Studio focuses on making the report design phase easier.

BKS Report Studio features several functions:
– Drag & Drop layout design for report templates
– Export as PDF documents or print directly
– SQL engine generates the necessary query and gathers data
– Filter data beforehand, or live at runtime with dynamic runtime filtering
– Boolean display is fully customizable, and supports Emoji
– Format numbers, and perform scripts on bands as they are generated

Connect to the most popular database engines, or connect to any database engine that provides an ODBC driver. BKS Report Studio supports these database engines: CubeSQL, MySQL, ODBC, PostgreSQL, and SQLite

BKS Report Studio is available now for Mac and Windows. Download it from the website for free today. Demo reports will be watermarked. Purchase a license for $175 to permanently remove the watermark and unlock the export-to-file functions.

Website: https://bksreportstudio.com
Download: https://bksreportstudio.com/download/auto
Purchase: https://bksreportstudio.com/buy

###

BKeeney Software is software consulting firm specializing in cross-platform, web, and mobile applications, developer tools, and training using the Xojo development platform.

support@bkeeney.com

 

Good Bug Reports

Bugs happen.  It doesn’t matter how much experience you have, or how much you test your code, a user will do something that you didn’t expect and your application behaves improperly.  Perhaps it throws an exception and reports it to the user and continues working.  Maybe your application quits on exceptions.  Either way, you have an unhappy customer that is reporting back to you.

“It’s crashing,” is a common phrase I hear in the Xojo forums and from our own users.  So the first question I usually have is “is it really crashing or is the application reporting an exception?”  The difference being, of course, one is controlled by me and the other is the application goes *poof* and there’s nothing controlled about it.  With the former I usually have some data that can help me figure out what’s going on and the second is a bad sign that it might be a plugin or library issue that I’ll have to track down.

What is their operating system and version?  

It’s important to know if they are running on Mac, Windows, or Linux and what version it is.  For Windows and Linux it’s important to know if it’s 32-bit or 64-bit.  You may end up having to send them instructions to determine what version they’re running depending on the end-users skill level.

What version of the Application/Library/Control are they using?

Applications are relatively easy to get version numbers from since the user can get this from multiple locations (usually).  Controls and libraries are a different matter and you, as the developer, should make this easy to find with documentation and constants in the code.

We’ve all had an email where a disgruntled customer says, “It doesn’t work!”  If you have multiple products this makes for an awkward return email asking which product they’re actually talking about.

Can they replicate the problem?  If so, what are the steps?

Customers often think that simply telling you about a problem is good enough.  Sometimes it is but usually I need more information.  The more detail the better.  If it’s a sequence issue I will sometimes ask for a video showing it in action.

Can they send you the error log?

If you create error logs it is helpful to get those.  To get the error Stack of an exception is useful and can sometimes tell you exactly what to fix if you’re lucky (especially with small/short methods!).

You may have to tell the user not only where they are but how to get the location.  Getting to the Application Support folder on Mac and Windows isn’t hard but it’s also not easy.  On MacOS the users Library folder is invisible by default.  On Windows this location is buried multiple layers deep.

Can they send you an example project or file?

With developer products it’s handy to get a small example project demonstrating the issue.  I can’t tell you how often simply asking for this solves the problem because they find their own mistake.  Even if it doesn’t you now have a good example project demonstrating an issue you didn’t know about!

With applications and utilities getting their data file is good.  There is nothing like working with real data to discover issues.

Users aren’t often helpful when it comes to asking for help with your products.  What other things do you ask customers when dealing with bugs?