Xojo is technical dept

Off-Topic
21

OK I see. I didn’t realise that was a link. I’ve not come across that term before, but then I’ve been retired for 13 years.

I would have said that changing technology should be done at a complexity boundary. I’ve watched some largish systems evolve and concluded that some time after initial introduction, requirements for extensions reach a point where they can’t be done within the bounds of the original design. So some things are added as hacks, but the effect is a possibly low, but constant, level of unfixable bugs - unfixable because the original design can’t encompass the extensions: fix one bug and another pops up instead.

I would define a system like that as having reached a complexity boundary. This means that it should be redesigned and re-implemented from the ground up. You may change technology at such points, but I wouldn’t just re-implement the same project. And I wouldn’t switch technologies mid-life.

1 Like
22

I wrote a highly encrypted desktop document management system in Xojo for a start-up.

When they decided to get funding, people said they needed access to the Xojo source code, and the source code of all plug-ins. When I said that this was impossible, and that even if we could have access for a short period of time, new releases would require re-analysis.

I asked them if they would require access to the Microsoft source code, if the project was written in .Net!

They decided to rewrite the whole project in ElectronJS and were ripped off severely by an Indian development company and never delivered. Two years later, they have now come back to me and asked if they can use my code again. If I do, my fee will have gone up substantially!

17 Likes
23

Hey David, Doing Xojo customer support I have heard more than a few stories like yours! Your fee should definitely be revisited :slight_smile:

7 Likes
24

Having run several TDDs in the past, Xojo’s current state with Web 2.0 being alpha quality in the main part and Android still not being delivered (after making reference in 2017’s Black Friday sale to new platforms cough Droid being included in active Pro license subscriptions at point of release) the use of Xojo would certainly flag an Amber.

We have to remember though that Xojo was one of the first (if not the first) to support M1 natively.

Xojo is great for proof of concepts and glue projects, and often for larger projects too.

The main consideration should be does it work (is it broken) and is it maintainable. If there’s a number of developers in the team and they know it that’s probably a yes - no need to rewrite in the mid term.

All a matter of perspective and opinion. And interesting post to read though!

2 Likes
25

Right on the target ! If you think Xojo or FileMaker are expensive, then try SAP. And SAP is only an ERP. Customizing SAP BusinessOne can be quite expensive, and if done inside, that can be slow.

I like that one. Those big corporations want their customers to pay high prices, but they want to have things for free ! Free has a price. More than often, support consists in using Google where your will find lot of information, from lot of peoples . . . not really helping, because everyone has an opinion.

Let’s say that someone picks VisualStudio for development. Yeah, it comes from a big company, it provides everything but the kitchen sink, but the price is not cheap. You want to buy a library of controls for .Net ? Again a lot of cash.

True, Xojo is not largely in use. The same is true for FileMaker. One of the reason is that high schools and colleges do not teach them. On top of that marketing needs big money. You can’t beat Apple and Microsoft at that. But that does not mean Xojo and FileMaker are not good products.

3 Likes
26

Me again about free tools.

Someone knows Google ? Yes for sure. This is no small company. They have introduce a lot of free tools and told people “come on and use them”. And some years late they pull the the plug on some. Repeat after me: THERE IS NOTHING FREE.

LOL Would they then release the source for their own tool built with Xojo ?

Sorry but the idea of getting the source code is joke. When you try hard to develop tools, why in the world would you give your work ?!|?!?!?

By the way for those who does not know, Xojo is written in . . . Xojo !

27

If the client wants the code to the project, the contract may state that with conditions.

But most customers will not need the code if we put a price tag on that.

1 Like
28

I remember 2 customers I did not work with in the 2000-2005 years because I was a too small business “not reliable”. they liked my project (and price) but I was too small for them to have business with me. 5+ years later I still was on business, and the people they choose didn’t ! it was big companies with 100+ devs that where reorganized and did not develop with the same tools so couldn’t maintain the customers apps they made anymore !

for a 3rd customer, they also did not choose me for the same reasons, and they had 3 different contractors that all did not finish the project (but took the money or a good part of it…) in the next 10 years. during that time, I made the app they needed with a friend, just for fun, and it works the way it should… this served me as a base for all my actual apps so it was not at all wasted time.

6 Likes
29

I’d be incredibly surprised if we didn’t all have stories like this, those of us that do contract development anyway. I’ve had a few customers over the years do the same thing.

Case in point: a fairly well-sized company (>100 employees) solicited a bid from me along with a questionnaire. I filled out the questionnaire and responded with a reasonable bid for the project. They went with another company that was 5% cheaper and had more employees. The project ran past the target date by months, went over budget, and they came back to me a few years later looking for a rewrite because of the poor quality and support they were paying for. They passed on my bid, as I was told, because “You’re just one person.”

It’s unfortunate that some factors are weighed far more heavily than they should be, in my opinion, in these processes.

7 Likes
30

From my personal experience, when it comes to whether an investor is going to sink money into your company - the answer simply comes down to your bottom line. Is there currently profit (or a strong indicator that there will be)? And will the business model sustain further growth?

Arguing the technical merits of Xojo (or any development tool) is simply a tactic to negotiate their return rate. The technical “risk” (or debt) to an investor is imaginary. They either see your company and/or product as a money maker, or they don’t.

If they do see it as a potential money maker, they want every argument available to negotiate how much of your profit they get to take home.

All the best!

8 Likes
31

ROFL HAve you heard about C, C++, C#, .NET, JAVA, GO, PHP, Python, JavaScript, Ruby, Swift, Flutter All of them are open source and offered for free and had a few millions more users than Xojo.

LOL, the IDE is written in Xojo, but xojo is not only the IDE.

3 Likes
32

I can only speak from my direct experience. Two of my customers are multi-billion dollar global companies. I have designed and deployed a number of desktop applications, primarily used in their Sales and Marketing efforts, for both of them over the past 7 - 8 years now. In the course of doing so, the revenue generated has paid all my bills, put food on my family’s table, given me a pretty nice life style AND allowed me to build a retirement nest egg that is very close now to hitting a 7-figure number. Not saying that in any bragging way whatsoever (quite to the contrary, I consider myself more blessed by God than any one man deserves in 10 lifetimes) … just adding the context to dimension my story.

Everything I do is in Xojo. I went through a thorough vetting process from both of the companies. The concern about my company being a solo act (me) certainly did come up as they inquired, “What would happen if the proverbial beer truck ran over me tonight?” In each case, I successfully defused that argument by pointing at the Xojo Forum and the pool of highly experienced developers, many of whom would jump on the opportunity to inherit the gig I now have, who could easily carry on with maintaining/modifying anything I created. I pointed out that like any other language, a Xojo programmer is a Xojo programmer is a Xojo programmer … it’s not the person but the language that provides the continuity.

Actually, what I found that they valued the most in an app was:

  1. That it works as advertised performing all the required functionality.
  2. That it was affordable (don’t read that as “cheap” … more like it is within their budget).
  3. That the design cycle met their timing needs and the product was delivered on time.
  4. That technical support was timely and effective.
  5. That any data involved (e.g., databases) was handled in a manner that was consistent with their internal security protocols
  6. And last, but not least, that I would seamlessly and efficiently integrate myself with whatever internal teams/individuals necessary to get the information I needed to completely meet their needs.

Both companies had unsavory experience working with larger “agencies” that had teams developing projects. They failed one or more of the points I outlined above. Each of the two companies gave me a chance by feeding me an initial project. When all was said and done, they both felt that they got a better deal from the “solo act” than they did from the “stud”. Any “technical debt” due to my being “small” was eliminated with the knowledge that they could contact Alyssa Foley at any time for a “replacement” in case I got hit by that beer truck tonight and continue on with business as usual.

Granted, these were not big system projects like a sales automation solution, and I realize that I may very well be the exception and not the rule (like I said, I know how blessed I am) … but my point is that there are companies out there who are capable and willing of looking beyond the “traditional measures” when selecting a source for providing their project needs. They look at what I provide as a “black box” and frankly don’t give a hoot if it was done with C, C#, Perl or Oyster! To them, the 6 points I listed above are their “measures”. They care that it does everything they need, brings them the promised value, and will never be an impediment to their business. So, here I am … almost 8 years later … and still doing so much business with both of those companies that it’s questionable whether I’ll ever retire (even though I could have several years ago).

22 Likes
33

Great story, and thank you for sharing! That’s what I meant with that it is more important to “deliver” than always hunting for the best possible tool, and not starting to realize anything. I used Xojo in the past decades in different jobs and different circumstances:

  1. Hobby: developing some tools for myself, family and friends, as I like to code. And with Xojo I did it for platforms and scenarios I never had in mind, just because I was able to do so.
  2. In less IT related senior management positions: because I did know Xojo and I wanted for instance to double-check the fancy figures some finance controllers or strategists gave to me and I didn’t believe them :wink: .
  3. In IT senior management positions: to quickly create a mock-up over the weekend to show developers what I actually had in mind, and where they had replied to me that it it will take 5 years at minimum. “Ok, now you have the idea, develop it in whatever language you like ;-)”.
  4. For internal tools in my above positions, where speed and functionality always beat “beauty”.

In my own business for the past 6 years:

Xojo as an enabler:
Xojo is great to quickly create mockups to get your foot in the door. Some customers continue with you and Xojo, some built up enough trust that we are able to meet their requirements, even if done in a different language or to supervise the execution by someone else.

Xojo as an efficient tool on low budgets
We have many NPOs, if they have the budget for dev, it is most often a one-time budget. They can’t predict nor plan to (financially) maintain the tool in the future. Most competitors have no interest whatsoever to help such organizations. For us it is quite easy to build something useful for them and with some experience it is not too risky nor complicate to price-in the future maintenance, especially as those customers are very happy that finally someone helps them. They are usually not too demanding so that maintenance is reduced to bug fixing, which should IMHO be free (priced-in upfront) anyways. And these customers are so happy if they get thing automated, that they will call you again, once they have a new budget to invest.

Of course, there are better and cheaper native tools out there, depending on what you want to achieve. And for sure one can reach a point, where it might be better to re-design the initial idea in something different. But those are rare examples and if they happen, I think this in general fantastic news: it shows that you build a success story. Today’s Facebook is a tiny bit different than what Zuckerberg “invented” originally, and they too did change technologies a few times. But again, for a big story to happen, you have to start!

In my current company, we are using different products as well, but I always like to start with Xojo, as I’m not aware of any other tool where I can be so fast in getting first ideas and prototypes up and running in no time. I was lucky to never have encountered a big show-stopper, there was always a work-a-round possible.

Granted, sometimes I had to adjust my original ideas. Of course, I have not always been happy with Xojo. Some changes, new promised features, bug fixing sometimes take an eternity or never happen at all, but I have seen this in many (all) tools. Some of them even died, and some died quickly, from one day to the other. The good news for me is that not only Xojo “survived” but as well the major plugin/add-on vendors. I invested some money in add-ons for other products, where the support ended out-of-the-blue - rarely happened to me in the Xojo ecosystem.

“tdd” is a topic on its own. As already mentioned, every investor wants to “negotiate”. You can compare it to the business of a public accountant: it is the nature of their business to find “something”, plus they might not be as independent as they sound and they might have other clients where it makes sense for them to push the chosen technology into a certain direction, be it just because they have already a bigger picture of future mergers and acquisitions in mind, ideas which they don’t share with you but apply as well to the chosen “internal” tools.

What surprises me after all these years, however, is that Xojo has not become more popular. I still see that as a flaw because, as mentioned above, it is often ridiculed. My own belief is that many users either use Xojo as a hobby only or for first self-education, and it is mainly used in companies that, for various reasons, do not share their knowledge publicly. So there are e.g. plugins that have been developed but are not sold but only used internally and companies usually have no interest to share success stories publicly.

11 Likes
34

I may point again to my feedback case 55135: Host an official Xojo consultants list

If Xojo Inc. would have a list of Xojo companies with links on their website, you could always say. If the bus hits me, you go to that list and contact a few of those developers to pick up.

7 Likes
35

I could write a one-thousand page answer in response to this post.

In an investment sense “technical debt” is the future price you pay for “making do” in the short-term.

Some describe it as cost of refactoring to a place of complete market acceptance. What would the market require of us (meaning what would investors like to see), and how do we get there? Jump through this burning hoop.

Technical debt (Argument 1) The decisions you made when you had $5 in your pocket, are assessed against the decision you would have made if you had $1M in your pocket. In simple terms, the difference between the values is arguably the deficit you need to bridge before becoming “truly” investment ready.

Technical debt (Argument 2) Did you make decision to stay alive? or did you make decisions on the basis that one day in the not too distant future you would need to be investment ready?

From the investor side of the table, it’s an attempt to belittle your business acumen and to lower the valuation of your business. “Oh they use Xojo/Filemaker/Ninox etc, hee, hee - how naive of them”. The argument is only ever valid when the investor is attempting to merge the logic of your business systems into a larger eco-system. “We refactor all acquisitions onto X dev stack”.

Technical debt lives in denial of the fact you did what you did, with the tools you could wrangle and despite any real or imagined shortcomings achieved success.

Technical debt lives in denial of the fact that systems evolve naturally (processes are constantly refactored) through business necessity and constant feedback loops.

Technical debt lives in denial of the fact that most innovation is driven by a few individuals that aligned themselves with accessible tools that allowed them to deliver the innovation at the heart of the business.

From my experience, the real technical debt is in documentation and in finding key personnel with an intimate working knowledge of systems. Why we apply the logic we do within the business.

Honestly, dev tools are a negligible factor if they are delivering reliable functionality. Dev platforms rarely go away completely and if they do, obsolescence is never instant.

Having sat on both sides of the table, the risks of acquiring systems that are not mainstream from an investor perspective is in fact a lesser risk than the risk of failure from refactoring software.

New software projects fail all the time across all languages.

My guess is your business was in part successful because the software written in Xojo has been functional / serviceable over a long period. That’s called stability and it’s a good thing.

Your issue is not a Xojo issue per se. Some investors will attempt to question every choice you ever made and make you eat that perception as a negotiating tool.

Kind regards, Andrew

12 Likes
36

After reading Andrew answer this comes to mnd:

“When you want to get rid of your dog you say he has rabies.”

And many other answers have key points.

A comparison with A&R in Music that was well know.

The Beatles was rejected from Record companies because “guitar groups are no more in the mood”.
The same guy signed The Rolling Stones some times later (one A&R guy said: “The group is good, but the singer…” he nearly ask them to fire Mick Jagger).

I can also give my example, but this is history (how some people can act against others) and will add nothing. Just an example: they ask me for a resume while the guy that talked about me was using a software I wrote nine years before and was happy with it. Go figure.

3 Likes
37

@Andrew_Paul_Dickey thanks for sharing, I can second all of your points from my experiences in the past.

On a side note it was no different when I used Xojo for my “internal” analysis in a multi billion global corporation: “Why did you not use our brand new BI system, why Xojo, what is Xojo, we don’t trust your figures from your “basic” tool, you are not supposed to develop, etc.” I only had the benefit that I had access to the databases of most systems (which no one cared about, but was actually wrong and something I had to change later.
My answer was always simple: well, because it works. Anything done with any of our internal systems would result in an ever-running project, with the risk to add more “errors” to that new project. If the source of data already contains mistakes, it doesn’t matter which tool you are putting on top. But I won’t build fancy Excel pivots on your data, which were already wrongly poured out of the databases.

Missing documentation of our data cemeteries was of course the biggest risk, followed by no overview, active monitoring, and maintenance of who was able to access which data. Even in my CTO days, my mantra (and put on every single powerpoint deck) was always: “Technology doesn’t matter”. Of course, that sentence is not completely right, but it was an eye-opener to many. It is first about analyzing what you want to achieve, and how, and then you decide about the tool/language which suits your needs, your competencies, and your budget in the best way. And surprisingly you can achieve a lot with Xojo and you can be very fast and by the simplicity of the language, the code is usually understandable by many.A And that’s important as unfortunately startups often don’t invest too much into a transparent documentation, especially not for internal tools.

2 Likes
38

Having seen what it did for me to prove continuity to prospective clients through the ready availability of Xojo programmers to pick up where I leave off, I think this is IMPERATIVE!. Each developer (consultant) could have their primary areas of expertise (e.g., desktop, web, mobile, network, etc.) which would make for a most efficient selection process. And it doesn’t seem to me that Christian’s idea would be too developmentally-intensive to not do it sooner rather than later. That would give the “official appearance” that we, as individual programmers, have a solid network (team?) behind us that could be drawn upon and collaborate as required to do larger projects as well.

1 Like
39

That is EXACTLY what I found to be the “line in the sand” where my value offering would not meet the customer’s needs. Nor, as I found the hard way, do I want to get into a situation where I’m required to get way down deep in the bowels of someone’s overall business system (been there, done that one time and never going back!). However, anything on the other side of that “line” is really fair game and if you know how to “sell on value”, then you can make a solid business case that your proposed solution touches more value points and is the best for the customer overall. The key is learning how to “sell on value” … if you can’t do that, you’ll never overcome the hurdles thrown at you in the name of “technical debt”.

3 Likes
40

Outstanding example, Emile! Paradigms change … the old “well we’ve done it this way for the past 20 years” is crumbling faster and faster these days. Companies are finding out that in order to remain competitive, they must think outside their stale corporate culture box. I’m finding more and more businesses that are willing to listen to the “small guy” … and if the “small guy” can show a better solution at a lower price with the security of having reputable tech service and lacking any potential liabilities (current or future), then they will go with the “small guy” … and quietly chuckle as they beat their competitor to the marketplace because they’re still waiting for their overpriced (just how do you think they cover all that headcount and overhead) agency product. That’s all part of “selling on value”.

2 Likes