Part 4 of my series on Xojo in the year 2017 and my thoughts on the challenges facing the tool and its framework(s) moving forward including my suggestions to help us all.
I think you missed the point of my blog post. Software development has to be fluid if you depend on others for parts of your product. Since Xojo is depending on others to develop LLVM and its toolset they have zero control over the LLVM release schedule. No amount of planning on Xojo’s part is going to change if/when the LLVM team makes a release.
We are seeing the result of that in R2. The Windows LLVM team is behind schedule (or whatever since we don’t know that root cause) so Xojo has to be fluid and adapt to changing conditions. Xojo gave a date/release on several occasions and has to move on without the promised functionality. They literally cannot do what they want because of someone else. That’s the fluid part.
From a Xojo user’s perspective I use MBS, Einhugur, and several other 3rd party libraries and controls on a regular basis. If there is a bug with one of them I have to depend on them to fix it since I don’t have the capabilities/desire to fix it. Einhugur StyleGrid is a great example of something that needs to be fixed but Bjorn is either unwilling or not capable of updating it. So if I’ve used it in an older project I have to be fluid when I do an update: I either stick with the project in Real Studio or I find an alternative.
In addition, it’s impossible to always know the level of effort for a bug fix or new feature until you actually do the work. Everyone comes up with an estimate and it’s almost always wrong. You can have a general idea but there are always unknowns - especially in large projects. If anything, I’d say the larger the project the more unknowns there are. Experienced developers with years of experience in the product have a better feeling for unknowns than say a newbie or a volunteer. Inexperienced or newbie developers will often ‘fix’ one bug and cause even more.
I remain unconvinced that open sourcing anything in Xojo would actually improve the product like you think it would. I think it would require a developer to review every single change to ensure that the change actually fixes the bug and doesn’t break something else. And depending on where the change occurs they’d have to ensure it didn’t break anything on all targets. Open source isn’t a panacea for an existing commercial project.
After reading @Phillip Zedalis and @Bob Keeney blog posts, I am more convinced that a commercial project you do as a small software company, can only be calculated on the proven technology and experience with it you already have.
Calculating with what is not proven, has been promised to come, or even worse, what has been promised based on what is totally out of anybody’s sphere of influence, is just the same as Russian roulette. 99.99% chance you end up doing a lot of unforeseen work around programming while trying not to exceed the schedule too much. Occasionally you will have to throw away a third party plugin/control not delivering exactly what you need.
In my current xojo project most of the third party components we planned to use, have been thrown out already prior to the first release, and replaced by what we could establish ourselves.
I would say: repeat the concepts and keep using the tools your are familiar with and don’t be tempted using the latest stuff which is still not proven to be successful to you for critical projects. Next , have your kindergarten for playing with everything which is nice but not critical for your business right now. In this playing area you keep yourself posted.
I agree that Software design is VERY fluid, take for example my current Tadpole project… it’s design and implementation evolved over that past several months into something much better than my original concept… Some might call it evolution, others might call it “scope creep”… to me it was a bit of each. If you take the concept that it is a piece of granite and your tool is a chisel, you don’t have a chance of doing anything more than rounding off a few sharp edges.
As to the subject of “open source”. I would much rather listen to an orchestra with a dedicated conductor, than a street band with less focus, less direction, and varying opinions on what good music is.
I have to agree with Joost regarding third party libs. I have been burned over and over with other IDE’S, Clipper, VFP, MiniGUI, etc. If I develop the tool myself I have complete control over it. When I use third party tools, I’m dependent on another source. I’ve taken the third party library shortcut many times and it always comes back to bite me. I bought the big omegabundle and have decided against using any of them. When I looked at the MBS help file I was blown away at the 27,000 pages of help. Are you serious? 27,000 pages? Like 54 reams of paper? He has so many tools, I cannot even guess what I need.
There are many talented programmers much more clever than me, and I respect the work they do, but they goof things up too. My bad is my bad, using someone else’s bad code would also be MY BAD…
Nah I get your point totally. I just choose to see it differently.
If by fluid we mean changes and adapts to outside pressures sure LLVM demonstrates where Xojo had to change their plans. However that says nothing regarding the many bug fixes that sit for months and even years with no resolution in sight. They have the full capability to work on those and they choose not to due to inertia, new features, rapid release, what have you. So it seems pretty clear to me that software development in Xojo in one example is a bit fluid and in the others quite solid because Xojo requires that only they get to chisel away at the bugs.
And that is perfectly fine because I am just throwing ideas out there on ways to improve the problems I see and others in the forum note. I will continue to throw out ideas because there is no harm in speculating how circumstances could be different.
Maybe Xojo would be more fluid if they allowed others to work on the things they are less interested in. For now though it seems to me Xojo is stubborn as a rock and only allow themselves to chisel on the product.
Keep in mind I agree with most of your sentiments Bob and merely used a different metaphor to describe the craft. We probably should not be debating the semantics of fluid vs solid when it comes to something as large as software development because as I demonstrated with Xojo it can be both at the same time.
[quote=344275:@Dave S]I agree that Software design is VERY fluid, take for example my current Tadpole project… it’s design and implementation evolved over that past several months into something much better than my original concept… Some might call it evolution, others might call it “scope creep”… to me it was a bit of each. If you take the concept that it is a piece of granite and your tool is a chisel, you don’t have a chance of doing anything more than rounding off a few sharp edges.
[/quote]
Fluid is responding to outside forces.
In your example you chisel’ed and re-chisel’ed core aspects of your program to make it better. That is great - neat product. You might be a sculptor.
