On Mon, Apr 11, 2011 at 4:57 PM, Evan Foss <evanf...@gmail.com> wrote: > Yea, I second the last part of the. If you have a large library of > parts done in a particular tool you will have to redraft all of them. > That is not good. > > On Sun, Apr 10, 2011 at 12:19 AM, <ge...@igor2.repo.hu> wrote: >> On Sat, Apr 09, 2011 at 10:51:00AM -0400, Bob Paddock wrote: >> >> <snip> >> >>> The developers always wanted to know "the fastest way" to do something >>> and had no interest in learning "the best way" to do something. >> >> Lately I had the chance to work together with professional software >> developers from multiple different western countries, and I have to tell >> you it is not china-specific. I think it's a generic big-company problem >> that you will see all around the world. >> >> Those developers work for money, not for joy, so fastest way is the only >> way for them, especially combined with the pressure from the management >> to deliver at deadline _and_ save cost (do it with less developers). >> >>> >>> In the end the company did ship Cellphones that some how did work. Is >>> that all that maters? I hope not... >>> Is this one company representative of all development in China? I hope >>> not... >> >> because of the above, in that big-copmpany environment it's very common >> to use duct tape all around. If there is a requirement and some well >> defined method that will be used to tes if the requirement is met at the >> end, you can be almost sure the developer will implement something that >> will work only for that one test case and will ignore the general idea >> behind th erequirement or the test case. This how sleep(1) kind of >> "fixes" end up in network code. >> >> I don't say it's because those developers are stupid or even >> inexperienced. It's more like the whole company culture. If you want to >> make things properly in such an environment, it will take more time and >> the feedback will not be "cool, you made some really robust, reusable >> code" but "next time please spend less on the golden knobs and >> concentrate on the task". Thus the best developers either leave after a >> while (either to other company or promoted to management) or they will >> start following the lazy methods knowing that it's not good, but "i have >> no choice". >> >>> Hopefully this will drive a lot more interest to gEDA and PCB. >> >> Honestly, I doubt. At the end once the user got used to whichever tool, >> he won't switch easily even if quality starts to go down. >> >> Regards, >> >> Tibor >> >> >> _______________________________________________ >> geda-user mailing list >> geda-user@moria.seul.org >> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user >> > > > > -- > http://evanfoss.googlepages.com/ > > > _______________________________________________ > geda-user mailing list > geda-user@moria.seul.org > http://www.seul.org/cgi-bin/mailman/listinfo/geda-user >
Altium have some great ideas but their execution is dire. They also spread themselves very thin by trying to encapsulate the whole embedded dev (Processor/FPGA) process into one tool, personally I think this was a huge mistake. As they've been loosing money for the last 10 years I cant say the move to China is shocking but I cant see it helping their execution woes. They're also hampered by a massive legacy code base in Delphi which essentially has no eco-system any more. _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user