Something that’s been nagging my curiosity for some time now is why I don’t see more XOJO forum members from India. Several of my client companies outsource a good amount of their programming needs to India. My largest client has an entire IT division there. I think it’s safe to say that computer programming has been a rapidly growing skill set embraced by many young professionals in India as the career path of choice. I have worked with a number of their programmers on various projects involving various programming languages and, in general, at least the ones that I’ve worked together with, seem to be very sharp (and efficient) coders who are highly logical thinkers and exhibit a well-structured thought process conducive to knocking out complex projects in relatively short order. Most I’ve worked with are proficient at multiple programming languages and platforms.
Using this forum almost daily as I do, I have seen folks from almost all parts of the world except India. With the seemingly large (huge?) base of IT professionals, let alone aspiring young coders (hobbyist or up-and-coming career programmers), it somewhat baffles me as to why I don’t see more presence from that country here. I’m sure XOJO has statistics as to the country of origin of all its users, but without visibility of that list I have no idea just how many are from India. It might be a telling sign that those programmers I have worked with from India had never heard of XOJO (or RB or RS for that matter) before.
Is my perception flawed and we really do have a substantial user base there who simply choose to be non participants in forum activity, or for some reason is India a “gap” in the XOJO global footprint?
Although India is a land of computing without which the Millennium Bug would have not been fixed in time, especially on ancient systems, it is not sure Xojo has as much attractiveness there as it may have in the US and Europe. At the time RB came to be, C and Java may not have been as prominent as today, when they are routinely taught in universities.
I may be mistaken, but I am under the impression that a lot of people who participate here have long passed their twenties, and a significant number started using RB around the turn of the millennium. Could it be a generational gap here, where a younger generation with another culture has less interest in our beloved Xojo ?
Is it not possible as well that although a lot of programmers from India do practice English, they might be more comfortable in their native languages, and rather use their own local forums ?
Christian statistics bring a lot of food for thoughts. How could a country so populated purchase as little as Greece ? Maybe Xojo needs an evangelist from that country with as much talent as Ulrich ?
Very interesting thoughts, Michel. It does seem on the surface to be distinct marketing opportunity for XOJO, to say the least. I would even take an Ulrich that didn’t play guitar! ^^
As far as a possible “generational gap”, I would think that today’s world of an ever increasing desire for “instant gratification” would drive younger aspiring programmers to seek a rapid development tool like XOJO.
I have sold apps to 21 people in Greece, and 7 in India. Greece is (still) a wealthy country. Coders in India are poorly paid by comparison and probably view Xojo as an impossibly expensive luxury.
My previous experience with such outsourcing deals is that the people you hire are not domain experts.
They’re coders. They don’t understand fluid dynamics when you need them to, payroll when you need them to, etc.
That may have changed but thats what I know I’ve encountered over the years.
And thats a problem.
And the niche that Xojo fills is different than the ones the people in India are targetting.
A huge chunk of our users are NOT full time programmers - they’re people who program as an adjunct to their job to get things done at work. As such they often ARE domain experts. Eugene is a great example of that.
And needing domain experts AND coders doesn’t fit well with the kinds of things I’m familiar with being outsourced.
This may be different depending on who you hire but thats what I’ve run into in the past.
[quote=205206:@Norman Palardy]They’re coders. They don’t understand fluid dynamics when you need them to, payroll when you need them to, etc.
That may have changed but thats what I know I’ve encountered over the years.[/quote]
Actually, Norman, when I think about it, my experience (still to current day) would match your description rather closely … darn good coders, but require lots of communication and explanation. Once they get that, they do well with the deliverable, but the hand-holding does come with a price.
They consistently (read that as 100% of the time) come in cheaper on quotes and that is an attraction to a few of my clients who are being driven to lower internal costs (read that as, “We don’t need in-house people on our payroll when we can outsource this without the benefits burden”) … considering the cost of the extra “communication” (I mentioned above in response to Norman), that is, in reality, “you can pay me now or you can pay me later”.
I’m not knowledgeable enough to know their income levels, so you’re giving me an education of sorts here, Matt … but I would still think that small businesses (i.e., 3 - 10 employees) would have the resources required since their income level as a business would support that kind of investment.
Even if their culture resembles that of our millennials, and that instant gratification can indeed be well served by Xojo, that would require them to know about it. Unfortunately, Xojo is not exactly top of the charts. These people learn flavors of C and Java in school, but I frankly doubt they are exposed to much else apart as a superficial mention of existence.
Besides, I suspect most of them tend to go with the flow, respond to offers by price rather than competence (cf Norman’s remarks), and do little research out of what is strictly needed to fill the contract.
You can pay me now or pay me later in a panic when you HAVE to get it fixed right
Been there done that - charged them 3x my normal rate and THEY had to pay the penalty for breaking a contract I was in (they negotiated with my then contracted site to do this)
18 months later it was all fixed & explaining it to Revenue Canada was fun (dunno how expensive it was but there was a penalty involved)
Very expensive lesson in several things
project oversight in such a relationship is CRITICAL and daily reviews are almost mandatory to catch issues early
make sure coders have domain knowledge is not expertise
learn about cultural differences
The last one proved to be VERY crucial.
I’d previously worked for one fellow who had overseen a team that included people from all over - india china canada the usa etc. He was very astute and had learned one thing - ASK everyone what they think BEFORE he opened his mouth & said what he liked. If he did things in any other way the people from China & India would never object or ask questions but just do what he said - regardless of how good or bad it was.
On this project the manager didn’t do that and got exactly that same response. No one raised concerns as it was seen to be “disrespectful” - so no obvious problems were brought up because “the boss” had said what he wanted.
That lead to a number of problems that the coders couldn’t deal with but plowed ahead anyway.
Oddly Western society isn’t quite as reserved about raising objections or asking questions of “the boss”.
the boss way of thinking is slowly disappearing, but was a real pain for the reasons you wrote.
I recall an article about that: the boss says use that tool (software) to do that and he gave very tight timing and at last, the workers were not prolific with that tool.
I suffer once 'bout that: Use PageMaker he said loud and less loud we do not have tools to convert the files to use them with QuarkXPress. And he does not knew I had one. I didn’t had time to discuss and for that (once) I do what was asked, and when it was done in time (gaven to the printer), I explain the boss the whole story. The next time, I do the things in my corner and do not ask anyone about anything and I dind’t had to work on Saturday AND Sunday.
Here is the thing, I’ve yet to see any innovate software applications coming out of India… I’ve worked with several outsourced teams over the past few years and it seems to me that they have only one focus - running/maintaining current systems as cheaply as possible. Most of the people I’ve worked with are not doubt highly intelligent and capable, but they don’t seem to be doing any little side project, no innovation etc… just learn what is needed for work, get a bit of experience and skip to the next job.
But the times they are a changing… I’ve noticed over the past year or so that many of the big companies in Zurich are moving away from India and looking more to Eastern Europe, where they are establishing their own development centers rather than outsourcing. I’ve heard some very positive feedback in that culture, mentality, team work, etc… are more in line with what is expected. Seems like the ability to speak English is not enough
I had experience planning and delivering a major ERP upgrade at a very large client where all the programming portion and most of the testing was done in India. We had a team of roughly 40 people in India and about half as many in Canada. I put in place a structure where I had a carefully selected Indian project manager off-shore. We also had a “off-shore coordinator” locally, whose job was to interact daily with the Indian PM. The project was not without challenges, but it was a great success.
While Indian programmers and testers were much cheaper by the hour than equivalent Canadians, the management structure that we put in place was expensive. We first flew our Indian PM to Canada to work with him for 2 full weeks (in the coldest weeks of January… but that is an other story) He returned with a clear idea of our expectations, of the project goals and of the project management standards. Where did this structure help?
1- We made sure we had a full time management team (of 2) handling the offshore team, working in close cooperation.
2- Our Indian PM interviewed every programmer and tester on that team, rejected many and only picked the best.
3- We had one person there with excellent language skills, excellent project management and a clear understanding of the project goals.
4- We had a local speaking the language and understanding the culture of our Indian team, able to align them with evolving priorities.
As I said earlier, the project was a great success. But we did not go offshore blindly. Cultural differences, time zone differences make communication difficult. India is certainly not monolithic as some seem to think here. Selecting the right people for the job is as important there as it is here, and in the end that is the way to success.
I am from India and I am a Xojo Pro License subscriber.
I am looking at setting up a small team which can work on Xojo Projects.
I am not a professional software developer, but me and my organization’s background is into electrical / electronics manufacturing.
I would now like to build a team that can work on software development as a standalone business model using Xojo. I am personally very comfortable with using Xojo and the support from this forum and hence would like to start building desktop / Web and Upcoming Android apps in Xojo. iOS Apps may not be too useful for our targeted user base, since iOS devices are pretty expensive in India.
Since I am not used to handling software development with a Team, I have no idea how to manage a team and get things done. I also don’t have any idea as to how to train the recruitment for software development. Further, since Xojo is a proprietary software, not everyone is accustomed to it, so hiring some experienced personnel is hard to find.
Can anyone kindly guide me as to how I can start with training the team. Can anyone please guide, how to prepare documentations such as system requirements and flowcharts, i.e. how to visualize and prepare.
Such a support will be surely helpful to establish a stronger base for Xojo in India.
How do you do your electrical/electronics manufacturing? You can apply your processes to the software part. In former times the requirements management for software was waterfall. That has changed to a more fluid process (look up “sprints”). But if you do know now to do requirements management then why should you change that?
Documentation depends on the size of the client. Use enterprise-y documents only when you have enterprise-y client. What do you need flowcharts for? You could even do the prototyping in Xojo.
Thanks for the valuable input. This is one of the greatest benefits that I find on being a part of Xojo. Everyone on this forum are willing to support and help. You really fell welcomed !
I shall definitely try and learn Agile Development Methology. Perhaps try an online tutorial to understand.
But beyond that, when it comes to software, working with a team, I do have some very basic fundamental questions on how to go about. Such as,
When developing a software, do we start with the UI screens first - develop all the UI interfaces and then work on linking them or is it vice-versa.
How to work with variables while working with Teams. How do we make people use the same connection variables. For eg : Someone may use VoltageInputVariable and someone else may use VoltageInput. How do we make the team speak in the same language.
How to document these things so that if we happen to restart a project after 6 months, with minimum efforts, we all understand how a code is written. While working on a single screen database capture related projects, this all is very easy. But working with Teams on a full-scale software, I find this unimaginable. Perhaps since I haven’t worked in any Software MNCs, I think I don’t know how the structure of compilation of codes from a wider resource base work.
Lastly, how do I train my team to use Xojo. Do I ask them to spend everyday for a month or two going through the Xojo Youtube Videos and then make some dummy apps to get used to the language, because I am pretty sure, I ain’t gonna find a single institute in India who would be teaching Xojo, just the way we have institutes for Java, Python and C++ or even for SAP.
I know that some of my questions are very basic, but I am confident that this forum is the place where I shall find the answers.
Thanks again for answering.
I think you should consider consulting by yourself first. Find a small sized problem in a business that doesnt have much other IT to gain some consulting experience. Dont expect to make much from your first contracts because it will take a long time to learn everything as you go, and youll make lots of mistakes and will have to do things again, which hopefully the customer wont see.
You start by finding out what the customer needs, what systems they have already, how much data is involved, how many end users etc. From this you decide on the best way to structure the solution. For example, if the small program is supposed to print barcode labels may be a desktop app. If the small program is supposed to record who enters or leaves a building maybe a Web app attached to a database.
Make a guesstimate of how many hours it should take to provide the minimum version 1 system, double that figure because it will take longer, and see if it fits the customers budget. If they dont have the budget allow them to pay it off as the program saves them money as your opening special. (Otherwise your first deal can be hard.) Then you might draw up a specification including some input and output screens (with no code) and get the customers approval. Make allowance for software installation, deployment and training the users and ongoing maintenance.
How to name variables is up to you. You can make some rules and keep them in a style guide so that later others can code the way you do. Generally, coders make up their own variable names using the style guide as a guide. In Xojo, variables that are fixed are typically object properties which shouldnt change or it will break the code of everyone using those objects. Variables names within a procedure arent so important to regulate. You can always use search and replace to standardise them later if you really want to. (You can do this with object properties too.)
If you use meaningful variable names with comments at the top of each procedure about what it does, your code will be largely self-documenting. You can also write system documentation about how the major parts work together, but if you need to do that for your first project its probably too big to be your first project!
You should train your programmers in the same way as you should train your self. Start them off with something small, so they can learn by doing. And fire the coders that dont learn fast! But dont expect to make a profit from them for many months because theres much to learn…
