Real Software Forums

The forum for Real Studio and other Real Software products.
[ REAL Software Website | Board Index ]
It is currently Sun Dec 09, 2018 8:57 pm
xojo

All times are UTC - 5 hours




Post new topic Reply to topic  [ 42 posts ]  Go to page Previous  1, 2, 3
Author Message
 Post subject: Re: Cocoa apps are really sluggish in the UI, is this normal
PostPosted: Wed Oct 24, 2012 8:28 am 
Offline

Joined: Wed Jan 12, 2011 12:48 pm
Posts: 53
Location: Fresno, CA
J.Sh3ppard wrote:
There is (or was) over 20 full time employees working at REAL Software but only about 5 or 6 full time coders.

What the heck is everyone else doing all the time?


More chefs in the kitchen won't necessarily make a better Chicken Parmesan.

_________________
Thanks,
Phillip Zedalis
Managing Developer
http://www.1701software.com
773-236-1701


Top
 Profile  
Reply with quote  
 Post subject: Re: Cocoa apps are really sluggish in the UI, is this normal
PostPosted: Wed Oct 24, 2012 10:47 am 
Offline

Joined: Tue Mar 23, 2010 8:44 pm
Posts: 673
pjzedalis wrote:
J.Sh3ppard wrote:
There is (or was) over 20 full time employees working at REAL Software but only about 5 or 6 full time coders.

What the heck is everyone else doing all the time?


More chefs in the kitchen won't necessarily make a better Chicken Parmesan.




You are correct under misguided leadership more workers may not equate to better production quality or faster production but in most cases it still does.

Workers don't do nothing at their jobs, even bad workers. They get work done but often at a slower pace and or with lower quality results.


Imagine that it is your job to paint the Great Wall of China and you are given a small paint brush. You must paint both sides and the top of the wall (all visible surfaces) using a small paint brush. This would probably take you a lifetime of painting and you probably would not finish.

Would you rather do this task alone or would you rather have the help of a single 5 year old child? You know the young child cannot paint nearly as well or as quickly as you can but you're also smart enough to know that the little 5 year old can paint quite a bit of the wall over the duration of the job (many years) and would be a significant benefit to the progress of the job greatly helping you accomplish the goal.

Clearly having two people is better than one. Even with the help of an unskilled person working on the job it would be completed sooner and with a higher quality than a single person alone could accomplish.

Even if the unskilled poor quality child did unacceptable work, the single adult could easily fix their missed spots faster than having to paint everything himself.

Add another 5 year old.
Now the task will be completed sooner and with a higher quality even if the adult would be required to correct the two 5 year old sloppy painting mistakes.

As time goes on the two 5 year olds gain more experience and they become higher quality and more efficient painters further helping you reach your goal at a quicker pace.


The more workers painting the wall, the faster the job gets completed. This would be true up to a certain point. Whatever that efficiency number is I don't know but it would probably be many millions of people. I would think once people could no longer fit their brushes onto the wall to paint and they start getting in each other's way we've reached or have neared the efficiency maximum number of workers.
At that point it becomes counter productive to have more workers.

Having so few coders working on the 'RS Great Wall' means RS isn't anywhere near the efficiency limit of development and they don't seem to be able to cover the quality gap or the feature 'to do' list. There are always too many bugs in each release and the technology is lagging behind the industry. It seems each coder is stretched too thin working on too many features to properly be able to maintain quality on those many features because they are told to 'move on' to the next task when they haven't properly tested and debugged what they just worked on.


Why do you think companies like Apple, Microsoft or Adobe have more than 5 - 6 coders working at the same time?

More workers (up to a point) working on the same project means faster production time and better quality under good management.


It sounds like you'd want Apple to only have 5 coders developing software, lol.


So who is to blame for the many bugs?

Do we blame the coders for not being careful enough checking for bugs before moving onto the next task or do we blame their leadership which tells them what to work on and when?

Maybe we need to also point the finger at the current workflow.
It takes more time and effort to have to fix a bug that is no longer fresh in the developers mind (because he has moved on to other features) than it would if the developer fixed the bug when he's working on that code and it's still fresh in his mind. By moving on to different tasks before the feature being coded is throughly tested and debugged it creates more work and less gets done resulting in inefficient use of developer time and a lower quality product for customers.
A bad result for everyone including RS.

Using customers to experience bugs, relying on customers to report bugs, then waiting for RS to 'discover' the bug reports, decide which bugs are to be worked on, make time to try to replicate the bugs then finally try to fix the bugs IF they were able to replicate the bug based on the report is far too slow and wastes too much time.

If there were far fewer bugs then this system would be effective but as it is there's way too many bugs in each release and too much time is lost using this type of system IMO.

Stop the bugs before they are distributed to the customers.
Fix the bugs before hand when the coders are working on the code and it will make things much more efficient and better for everyone.

I wonder how much time is wasted on reading and dealing with the massive number of bug reports, deciding on which bugs are to be worked on, then time taken to try to replicate the bugs, writing the feedback or customer communication?

Even if it's not RS developers doing all of that it's still a waste of company resources because whoever does that could be replaced by a coder fixing the product.

It's terrible.


RS seems to want to be this huge marketing machine putting REAL Studio all over the world so it can sell more copies while letting quality fall. I think the truth is, if you have high quality products your customers will be one of your best assets. They will be a large part of your marketing machine and they will do this for free. With low quality products, you will destroy your reputation and no amount of marketing 'spin' will turn that into consistently high sales. People learn the truth and know what to avoid and over time you will wilt and fade away.


I think this company also keeps too many secrets from it's customers. RS are in need of improvement and many of it's customers are intelligent and would gladly offer suggestions on improvements. But without knowing the internal workings of the company it's hard to offer any concrete advice on what should be improved or how to specifically improve it.

Why all the secrets? What are they afraid of?

Oh well, another day another day.


Top
 Profile  
Reply with quote  
 Post subject: Re: Cocoa apps are really sluggish in the UI, is this normal
PostPosted: Wed Oct 24, 2012 12:33 pm 
Offline

Joined: Wed Jan 12, 2011 12:48 pm
Posts: 53
Location: Fresno, CA
J.Sh3ppard wrote:

You are correct under misguided leadership more workers may not equate to better production quality or faster production but in most cases it still does.



Well I don't know if their leadership is misguided or not. I don't often agree with them and I know others don't always as well. However there isn't much to compare it too. Runtime Revolution operates very differently while selling a tool that's similar in purpose. I don't believe I have the tools to adequately assess or evaluate Real's leadership.

J.Sh3ppard wrote:

Workers don't do nothing at their jobs, even bad workers. They get work done but often at a slower pace and or with lower quality results.



I have worked at and/or consulted with some of the largest companies in the World. My experience is the opposite of yours.

J.Sh3ppard wrote:

Imagine that it is your job to paint the Great Wall of China and you are given a small paint brush. You must paint both sides and the top of the wall (all visible surfaces) using a small paint brush. This would probably take you a lifetime of painting and you probably would not finish.

Would you rather do this task alone or would you rather have the help of a single 5 year old child? You know the young child cannot paint nearly as well or as quickly as you can but you're also smart enough to know that the little 5 year old can paint quite a bit of the wall over the duration of the job (many years) and would be a significant benefit to the progress of the job greatly helping you accomplish the goal.

Clearly having two people is better than one. Even with the help of an unskilled person working on the job it would be completed sooner and with a higher quality than a single person alone could accomplish.

Even if the unskilled poor quality child did unacceptable work, the single adult could easily fix their missed spots faster than having to paint everything himself.



Yes in your extremely elementary example two is better than one. However if you think creating Real Studio can be done with adding 5 year olds you may need to educate yourself about software development more.

J.Sh3ppard wrote:

Having so few coders working on the 'RS Great Wall' means RS isn't anywhere near the efficiency limit of development and they don't seem to be able to cover the quality gap or the feature 'to do' list. There are always too many bugs in each release and the technology is lagging behind the industry. It seems each coder is stretched too thin working on too many features to properly be able to maintain quality on those many features because they are told to 'move on' to the next task when they haven't properly tested and debugged what they just worked on.



I personally do not know what they are told to do. I certainly don't have any knowledge of them being told to 'move on' to the next task. Do you have insider information of being a coder at Real Software you would like to share?

J.Sh3ppard wrote:

Why do you think companies like Apple, Microsoft or Adobe have more than 5 - 6 coders working at the same time?



They have more than one product perhaps?

J.Sh3ppard wrote:

More workers (up to a point) working on the same project means faster production time and better quality under good management.

It sounds like you'd want Apple to only have 5 coders developing software, lol.



I believe Apple knows what it needs to do. I'm not saying they should do anything.

J.Sh3ppard wrote:

So who is to blame for the many bugs?

Do we blame the coders for not being careful enough checking for bugs before moving onto the next task or do we blame their leadership which tells them what to work on and when?

Maybe we need to also point the finger at the current workflow.
It takes more time and effort to have to fix a bug that is no longer fresh in the developers mind (because he has moved on to other features) than it would if the developer fixed the bug when he's working on that code and it's still fresh in his mind. By moving on to different tasks before the feature being coded is throughly tested and debugged it creates more work and less gets done resulting in inefficient use of developer time and a lower quality product for customers.
A bad result for everyone including RS.



Well like I said without inside information into Real Software's inner workings it's difficult to determine. I'm also not entirely sure it matters who is at fault for bugs.

I mean if the product does what you require then use it. If not, use something else. I believe some of the negativity revolves around people who otherwise could not be software developers using the tool. They either fault their lack of knowledge or the tool as to why they are unproductive and then go on a Holy War against it. The most productive approach would be to use something else.

Almost any sane logical person would come to that conclusion. So I can only conclude for some portion of the customer they either can not or will not use something else.

I understand that Real should have a product that is completely tested and rock solid. However in software that is very hard to do, especially on the scale that they operate. While I am disappointed when things do not work correctly, there's nothing I personally can do about it. These forums posts for instance are not improving Real Software or enlightening them on how to produce a better product. It's just spreading negativity and subjective opinions on behalf of users who struggled.

I can only assume there are other users who use the product just fine as they are still in business.

J.Sh3ppard wrote:

Using customers to experience bugs, relying on customers to report bugs, then waiting for RS to 'discover' the bug reports, decide which bugs are to be worked on, make time to try to replicate the bugs then finally try to fix the bugs IF they were able to replicate the bug based on the report is far too slow and wastes too much time.

If there were far fewer bugs then this system would be effective but as it is there's way too many bugs in each release and too much time is lost using this type of system IMO.

Stop the bugs before they are distributed to the customers.
Fix the bugs before hand when the coders are working on the code and it will make things much more efficient and better for everyone.

I wonder how much time is wasted on reading and dealing with the massive number of bug reports, deciding on which bugs are to be worked on, then time taken to try to replicate the bugs, writing the feedback or customer communication?

Even if it's not RS developers doing all of that it's still a waste of company resources because whoever does that could be replaced by a coder fixing the product.



Well you don't really know how many hours per week a developer is in the bug reports system. Nor have you acknowledged that even if their pre-distribution workflow were different they would very likely still have a bug reports system of some kind they would have to work with.

A great deals of bugs are often the user not understanding how to use the product. So there's a lot of education and such necessary. I know large improvements are in the works for better documentation and resources. I also know the language references and wikis are vastly improved over past years.

So there is progress on the user education front.

J.Sh3ppard wrote:

It reminds me of bad software coders who write inefficient code and when their customers say " It's too slow ", bad software developers say the solution is to "Buy faster hardware". Many times if they optimize their code the faster hardware isn't needed. When you're dealing with hundreds or thousands of servers it costs the customer incredible amounts of money.



This same debate came up when Ruby on Rails was first introduced. The logic was fairly straight forward. Developer time is expensive. Hardware prices are constantly decreasing and increasing in capabilities. It makes sense to throw hardware at the problem MOST of the time.

That being said Real could do a few things to improve it and they are. Multi-core aware, 64-bit in high memory usage situations, etc. All things considered Real has always been 'fast enough' for me.

J.Sh3ppard wrote:

RS seems to want to be this huge marketing machine putting REAL Studio all over the world so it can sell more copies while letting quality fall. I think the truth is, if you have high quality products your customers will be one of you best assets and they will be a large part of your marketing machine and they will do this for free. With low quality products, you will destroy your reputation and no amount of marketing 'spin' will turn that into consistently high sales. People learn the truth and know what to avoid and over time you will wilt and fade away.



True of any company.

J.Sh3ppard wrote:

I think this company also keeps too many secrets from it's customers. RS are in need of help and many of it's customers are fairly intelligent and would gladly offer suggestions on improvements but without knowing the internal workings of the company it's hard to offer any concrete advice on what should be improved.

Oh well, another day another day.


Yes they are very secretive. I do not believe they like to over-promise and under-deliver. Had they never told us they were working on Cocoa their failings would not be so public and people wouldn't have been so upset. Then again, they may have less customers because many renewed on the promise it was coming. It's a delicate balance and marketing/sales is just as complicated as software development.

P.S. It's considered bad form to edit your post and append to it. Every time I come in to consider a thoughtful response your post has gotten larger.

_________________
Thanks,
Phillip Zedalis
Managing Developer
http://www.1701software.com
773-236-1701


Top
 Profile  
Reply with quote  
 Post subject: Re: Cocoa apps are really sluggish in the UI, is this normal
PostPosted: Wed Oct 24, 2012 1:59 pm 
Offline
Real Software Engineer

Joined: Sat Dec 24, 2005 8:18 pm
Posts: 7858
Location: Canada, Alberta, Near Red Deer
J.Sh3ppard wrote:
Why all the secrets? What are they afraid of?

Rants like this.

_________________
Norman Palardy (Real Software)


Top
 Profile  
Reply with quote  
 Post subject: Re: Cocoa apps are really sluggish in the UI, is this normal
PostPosted: Wed Oct 24, 2012 9:58 pm 
Offline
User avatar

Joined: Fri Sep 30, 2005 11:00 am
Posts: 583
Location: Beautiful Taiwan
J.Sh3ppard wrote:
pjzedalis wrote:
J.Sh3ppard wrote:
RS seems to want to be this huge marketing machine putting REAL Studio all over the world so it can sell more copies while letting quality fall. I think the truth is, if you have high quality products your customers will be one of your best assets. They will be a large part of your marketing machine and they will do this for free. With low quality products, you will destroy your reputation and no amount of marketing 'spin' will turn that into consistently high sales. People learn the truth and know what to avoid and over time you will wilt and fade away.

I think this company also keeps too many secrets from it's customers. RS are in need of improvement and many of it's customers are intelligent and would gladly offer suggestions on improvements. But without knowing the internal workings of the company it's hard to offer any concrete advice on what should be improved or how to specifically improve it.


From personal experience over time, I've locked horns with Geoff a couple of times and most likely jumped to conclusions and possibly even said things that I shouldn't have.

However the last couple of times, I've had concerns or issues. I've contacted RS staff in a very polite manner, explained my issue and what I believe needs to be done in order to improve RS for my needs. One time, it took me a week to send the e-mail as I altered it every day until I thought it clear, concise and most of all productive.

Since I've taken this attitude when dealing with RS, I've had nothing but good conversations with Geoff and others. Some of my concerns may not be addressed as quickly as I like, but I'm more confident in the knowledge that RS is listening to me (and other customers) and they do pay attention. As a result I'm happy to continue using RS to develop our applications with.

I tried the same approach with another company that we had issues with... They were not so responsive to my e-mails and as a result I'll be taking my business away from them in the future.

If you are not already, I would suggest at the very least, becoming an active member of the beta testing community. This is a prime opportunity to highlight and emphasize bugs that could reduce the quality of your application. You not only help yourself, but you also help RS in producing a more reliable and stable product.

_________________
Sam Rowlands
rMBP 15" @ 10.8 & '08 MBA 13" @ 10.6 + 10.7, RB2012
http://www.ohanaware.com/
AppWrapper - Prepare Apps for Mac App Store & OS X 10.8 - http://www.ohanaware.com/appwrapper/


Top
 Profile  
Reply with quote  
 Post subject: Re: Cocoa apps are really sluggish in the UI, is this normal
PostPosted: Thu Oct 25, 2012 12:01 am 
Offline

Joined: Sun Oct 17, 2010 9:46 am
Posts: 83
Location: Berlin, Germany
The usesThreadedAnimation property of the NSProgressIndicator is set to YES by the RB Cocoa framework:
Declare Function usesThreadedAnimation Lib "Cocoa" Selector "usesThreadedAnimation" (receiver As Ptr) As Byte
MsgBox Str(usesThreadedAnimation(Ptr(Me.Handle)) = 1) // -> True

You can turn this effect off by doing:
Declare Sub setUsesThreadedAnimation Lib "Cocoa" Selector "setUsesThreadedAnimation:" (receiver As Ptr, flag As Byte)
setUsesThreadedAnimation(Ptr(Me.Handle), 0)
Now the ProgressBar behaves like the Carbon one.

So this is not a programming error at all by RB, since the animation is exactly the same in Objective C with setUsesThreadedAnimation: set to YES (I quickly tested it).

But one could classify it as a design error, since in RB things are usually kept as simple as possible and consistent over the three platforms. So RB maybe should have all these Cocoa default animations turned off by default.


Last edited by eliott on Thu Oct 25, 2012 12:25 am, edited 1 time in total.

Top
 Profile  
Reply with quote  
 Post subject: Re: Cocoa apps are really sluggish in the UI, is this normal
PostPosted: Thu Oct 25, 2012 12:04 am 
Offline

Joined: Fri May 08, 2009 1:42 am
Posts: 71
npalardy wrote:
Rants like this.

Not exactly how I talk to my customers, especially after one of them expressed a lot of frustration in an email or post. In fact, I have just one employee, and I'd fire her happy ass if she popped off like this more than once to a customer airing out complaints. A lot of what J.Sh3ppard says is off base and ill informed I am sure, but this isn't helpful. It *has* felt like we have been in the dark this year. The communication has been fairly poor on what to expect during the license / IDE / Release schedule changes and disruptions.


Top
 Profile  
Reply with quote  
 Post subject: Re: Cocoa apps are really sluggish in the UI, is this normal
PostPosted: Thu Oct 25, 2012 1:47 am 
Offline

Joined: Tue Mar 23, 2010 8:44 pm
Posts: 673
pate wrote:
A lot of what J.Sh3ppard says is off base and ill informed I am sure


Really? Do you honestly believe that?

I would like to hear your opinion of what you are sure I am wrong about.

Customers are not at fault here. We pay for the product and it is supposed to work when we buy it. When it doesn't work correctly and it causes us a lot of problems and things don't seem to get much better with the various releases I think it's good to voice our concerns to the company. They need to know we're counting on this product and it's not acceptable to us if it's not working. In my opinion a smart company would want to hear where they need to improve and they'd want this feedback directly from their customers.


For every action there is an equal and opposite reaction. OK.
If RS doesn't like customers being upset and writing about it, the solution is very easy. Don't sell broken product. If some issues are sold, fix them quickly and without extra fees.
How a company employee blames customers for voicing their legitimate concerns and disappointments is unfounded.

How customers should be treated.
I recently bought some products for my cat at Petco.
One of the editable items I opened and tried to feed some to her.
She hated it and wouldn't even touch it.
The store employee had told me 'Cats really love this stuff, it will make her calm and feel relaxed, etc. ' so I wanted to try it.

I took it back to the store and the store manager gladly refunded my money. No hassles at all. I even said to him, I opened this stuff and my cat hated it so I don't know if you'll refund my money but you can have it back even if you don't refund my money cause my cat won't touch it.

That's how customers are supposed to be treated.


A little while ago I went out to eat at a nice restaurant and I was wearing a nice dress shirt as it was an important night out.

As the cute waitress was taking my menu from me she accidentally spilled my beer all over me (my shirt and pants). About half my shirt and practically all of my crotch region was drenched in beer as the entire glass dumped on me.

What was my reaction?
I started laughing.
Why?
Because in life mistakes like this happen and things like this aren't a big deal and not worth getting upset over. The cute waitress was very upset and apologetic and at first didn't realize I was laughing about it and that I was not upset with her. After a while she was smiling again and we were playfully joking about it. She apologized about four times throughout the night. Anyway after I cleaned myself up in the bathroom and returned to the table the manager came over and offered to dry clean my shirt and pants which I politely refused and said it was no big deal, stuff happens. No worries.

I guess she was delighted with that because they ended up comping the bill.

That's how customers are supposed to be treated.

When a company screws up they do their best to make it right for the customer.
They appreciate the customers and are smart enough to realize without the customers there is no business.
They don't make excuses or blame the customer when the product or service is problematic.
They do their best to immediately correct the problem for the customer and make the customer's experience a positive one.

I imagine when most guys get a beer spilled on their nice clothes they freak out or at least get pissy especially when it's a special occasion dinner. You guys might be surprised that I don't get upset by life's small issues by what I sometimes post on here.

What's the difference?
The difference is when a company sells a product that is very important to my business and income and it's often not working correctly it creates a lot of problems and loss of money for me. It also creates a lot more work than it is supposed to be. This is why I sometimes complain about the quality issues. It helps keep the company on target.

We are the customers. We buy this product. It is not our fault it's broken and often causes us trouble. It is not supposed to be that way. We have every right to be upset about this and voice our concerns. If REAL Software were only occasionally spilling beers on my shirts and pants I wouldn't care. That's not something worth getting upset about. But when their screw ups are repeatedly costing me a lot of money or requiring significantly more time and work to accomplish the job than it should require there is reason to be upset and be vocal about it.
That is how you let the company know they need to improve.


Btw, I wouldn't call what I wrote a rant. If you want to hear me rant about something here's a glimpse about what morons work at the DMV. They've screwed up various vehicle registrations, non-ops, and affidavit of non use statuses for me when I've followed their exact instructions while speaking to them on the telephone and executing the steps on their website (or in person at the local DMV). Their website confirmed I did the various things correctly as did the DMV employees (more than one phone call) but magically a year later there's no record of my filings and they want to charge me excess money for late fees, etc.

In one case they want over $800.00 dollars in back registration because they mysteriously never processed a non-op I had filed for a vehicle years ago in person at the DMV while the DMV clerk verified it was filled out correctly and then took and processed my money to do it! Meanwhile they also magically claim to of lost my address as they were never mailing me registration renewal notices over the years for this vehicle. Naturally I had no idea the non-op wasn't filed and assumed the morons at the DMV had correctly processed the non-op as it was done IN PERSON at the DMV. Since I was not getting any registration renewals notices for that vehicle I had no reason to suspect otherwise. But I was wrong. They are probably the most incompetent idiots I've ever dealt with in my life.

While that was going on they did still send me other vehicle registration notices so yes they had my mailing address on file all along. Who knows why they never processed my non-op on said vehicle but also never sent me any renewal registration notices meanwhile they took my money for the non-op fee and 'absorbed it' (yes that is the term they used) into DMV funds while doing nothing for me. It's criminal. It's nuts. It's retarded. But is it worth hiring a lawyer for? Probably not. Do I hate some DMV workers? Hell yes.


REAL Studio is very important to me.
This is why I spend my time voicing my concerns and customers have a right to do this and should do this.


Anyway WhatEvs.


Top
 Profile  
Reply with quote  
 Post subject: Re: Cocoa apps are really sluggish in the UI, is this normal
PostPosted: Thu Oct 25, 2012 2:57 am 
Offline
User avatar

Joined: Fri Sep 30, 2005 11:00 am
Posts: 583
Location: Beautiful Taiwan
eliott wrote:
The usesThreadedAnimation property of the NSProgressIndicator is set to YES by the RB Cocoa framework:
Declare Function usesThreadedAnimation Lib "Cocoa" Selector "usesThreadedAnimation" (receiver As Ptr) As Byte
MsgBox Str(usesThreadedAnimation(Ptr(Me.Handle)) = 1) // -> True

You can turn this effect off by doing:
Declare Sub setUsesThreadedAnimation Lib "Cocoa" Selector "setUsesThreadedAnimation:" (receiver As Ptr, flag As Byte)
setUsesThreadedAnimation(Ptr(Me.Handle), 0)
Now the ProgressBar behaves like the Carbon one.

So this is not a programming error at all by RB, since the animation is exactly the same in Objective C with setUsesThreadedAnimation: set to YES (I quickly tested it).

But one could classify it as a design error, since in RB things are usually kept as simple as possible and consistent over the three platforms. So RB maybe should have all these Cocoa default animations turned off by default.



Thanks for posting the declare - this should help the OP and others who have the same question. And no I don't think that they should disable the animation by default.

_________________
Sam Rowlands
rMBP 15" @ 10.8 & '08 MBA 13" @ 10.6 + 10.7, RB2012
http://www.ohanaware.com/
AppWrapper - Prepare Apps for Mac App Store & OS X 10.8 - http://www.ohanaware.com/appwrapper/


Top
 Profile  
Reply with quote  
 Post subject: Re: Cocoa apps are really sluggish in the UI, is this normal
PostPosted: Thu Oct 25, 2012 10:46 am 
Offline

Joined: Fri May 08, 2009 1:42 am
Posts: 71
J.Sh3ppard wrote:
Really? Do you honestly believe that?

I would like to hear your opinion of what you are sure I am wrong about.

Dude, calm down, I'm on your side. What I meant was the folks at RS have a lot more information on this topic that you are not privy to. While I think we have every right to complain about the bugs, delayed schedules, general direction of the product, I don't think any of us are in a position to be talking about the number of coders that need to be on a project. We just don't have access to revenue numbers, feedback data from surveys, and market research that is driving their decisions. A lot of what you said I agree with. I think they have a buggy product. I think it is partially due to fanning out in too many directions and not making bug fixing the #1 priority. I'm not saying that cross-platform IDE / compiler work isn't difficult, I am sure it is. Their programmers are probably 10 times the coder I'll ever be. But it doesn't change the fact that I can crash the RS IDE roughly 20 times as often as other IDEs I work in. Just my 2 cents on reading thousands of user posts here as well as developer forums all over the Internet.

On the flip side that doesn't give the RS programmers the right to come on the USER FORUMS and make condescending and dismissive remarks. But hey, its Geoff's company, he can let his programmers post however he wants.

p.s. Those are rants. You could have made your point in 1/10th the space.


Top
 Profile  
Reply with quote  
 Post subject: Re: Cocoa apps are really sluggish in the UI, is this normal
PostPosted: Thu Oct 25, 2012 12:54 pm 
Offline
Real Software Engineer

Joined: Sat Dec 24, 2005 8:18 pm
Posts: 7858
Location: Canada, Alberta, Near Red Deer
In all seriousness the question posed was "what are we afraid of"
I replied with exactly what we're afraid of - if we tell people a lot about plans, directions etc that lead to rants about "you promised ...."
For many years Real did not share ANY plans with anyone outside because of this exact problem.
They got blasted for that - so we decided we could start doing that again and now we get rants about how "version X isn't going to include feature Y but you said ....."
So we're back in the position of sharing plans then getting blasted forNOT being able to deliver the kind of product we want in the time frame we expected to.

Rants about bugs, quality do little to help anyone make the product better.
Good bug reports are much more useful & much more likely to actually end up with actions that fix/correct the issues.

_________________
Norman Palardy (Real Software)


Top
 Profile  
Reply with quote  
 Post subject: Re: Cocoa apps are really sluggish in the UI, is this normal
PostPosted: Thu Oct 25, 2012 1:39 pm 
Offline
User avatar

Joined: Fri Sep 30, 2005 11:48 am
Posts: 3554
Location: Lenexa, KS
Quote:
Good bug reports are much more useful & much more likely to actually end up with actions that fix/correct the issues.


I discovered years ago that providing simple and reproducible projects with my bug reports is the #1 way to get them fixed in a timely manner. That, and buying a round of drinks at Real World go a long way. :D

Seriously, we all get frustrated from time to time with things that don't work like we expect. Being calm and rational and removing the emotion is better for everyone involved.

_________________
Bob K.

A blog about being a Real Studio/Xojo developer at http://www.bkeeneybriefs.com


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 42 posts ]  Go to page Previous  1, 2, 3

All times are UTC - 5 hours


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group