Programming with
a dose of satire.
Soapbox
|
| ||||||||
 |
 |
|||||||
|
Soapbox |
||
The Fallacy of Cheap ProgrammersBy Robin Sharp The recent downturn in the software industry brought with it an influx of cheap, inexperienced programmers. In this article, Robin Sharp discovers that lately, the bulk of his work has involved fixing their mistakes... A pint of Beer and a Packet of Programmers, Please. Ever popped down the pub and bought a pint of beer and a packet of crisps? Well what about programmers, can you just pop out and pick up a few, like packets of crisps? For programmers, there really isn't such a thing as an off the shelf commodity. There's a parallel here with the marketing of enterprise solutions. Enterprise solution marketeers use a compelling sales pitch: that enterprise solutions are commodities that can be picked off the shelf. We're constantly being told: "If you buy this product, all your enterprise solutions will be solved!" I think more of us should complain to the advertising standards authorities. Managers are told that enterprise solutions are now just a matter of a point, a click and a deploy away. However, anybody who uses these solutions will tell you that there is a very large gap between the hype and the reality. In my experience, you shouldn't expect too much from enterprise application servers unless you have a good knowledge of transaction managers, defensive programming, distributed programming and much, much more. Given the learning curve I'm not surprised how few enterprise application server projects make it out the door. Just like enterprise 'solutions', senior management want to believe that programmers are commodity items as well. Management don't like the idea that creating software is expensive (even though there's enough expensive software out there to prove that it is). They want to believe there is a cheaper option. So they are susceptible to unscrupulous sales people who sell the line that programmers are "commodities that can be taken off the shelf". Like crisp packets or TVs, if one is too expensive they can be swapped for a cheaper one. Ultimately they want to believe you can pop down to Radio Shack and pick up a packet of programmers. If you believe the story that programmers are commodities then it follows that the price of programmers is determined by supply and demand, and costs of production. However the argument is self-defeating, because programmers follow the same economic laws as supply and demand. As soon as they prove themselves to be good programmers, they are in demand and leave the cheap sweatshops for sunnier shores. But I'd argue that you can't simply pick up a 'good' programmer from one environment and dump them in a different one and expect them to code correctly. Like our packet of crisps, even programmers come in different flavours. A skilled real-time programmer dumped in an investment bank would probably write code that is culturally too diligent on some aspects and not on others: ultimately creating expensive risky code. It may sound flippant to say there is a world of difference between a graduate writing a program to enter data into a non-critical application and a core trading application, but to the untrained eye there probably isn't. In fact, as a manager once said to me, my robust software is 'all messed up' by all the execption handling, validation and logging.
Is Management in Denial? A lot of research on programmer productivity shows that the best programmers are up to 20 times more productive than the worst programmers. If the income differential between the best and worst programmers is even 5 times, it means employers are getting incredible value for money hiring the best programmers. Why then don't companies hire a few very good programmers and leave the rest flipping Big Macs? There is one very good reason: the psychology of managers. Managers simply can't believe that one programmer can be as productive as 3, let alone 5 or even 20 times. Managers believe that productivity is a management issue. They believe that simply by re-organising their human resources it is they who can gain leaps in productivity, and reap the rewards. But the reality of management, as we all know, is that most projects are late and over budget. The very existence of a project manager role is based on the weak assumption that the ability to be productive is handed down from management "on high", based on their reorganisation skills. I think management don't want to hear that a single programmer could (if left to their own devices) out code an existing team. That would mean that the programmer would be worth more than the manager and that the manager’s role would be redundant. The notion that perhaps all programmers are not born the same is a matter of deep psychological denial for some managers. A good example of management reality-denial is the deeply flawed CMM (Capability Maturity Model) where the goal is to make all projects repeatable. To do this the methodology tries to eliminate the need for the hero-programmer. The methodology argues that if all the tasks in a project were documented then a different set of programmers could undertake them, the project timescale could be planned and be on budget. The reality is that all projects are fundamentally different, address different business needs, using different technology that changes almost monthly and requires deep understanding and creative input to make the software profitable. With the CMM there is no "creative" box nor is there is a "great idea" box, nor is there a "talent" box nor are there "hard-work" or "highly focused" boxes. Despite the outside view of programmers being nerds without personality, great programmers have the ability to blend creativity, strategy and attention to detail. It is obvious that any 'successful' CMM project will either be down to getting very, very lucky or having a programmer on board who understands what is really needed and playing along with their manager. Grace Hooper (the person who designed COBOL) had a motto which should be the mantra of every programmer on a CMM project: "It is better to seek forgiveness than seek permission".
Conclusion One of the defining characteristics of the past 3 years of my working life is how much software I am having to 'fix'. This is principally because a lot of the 'expensive' programmers were excluded from the market for a couple of years - dumped out while the industry looked naively for ways of cutting costs. As a result, there's a lot of software around that is less than optimal. This problem has been multiplied by the introduction of "off-the-shelf" enterprise application servers at the same time. Now that the market is picking up, we're starting to see an increase in demand for programmers, and some green-field projects. Anybody thinking they can staff up a project with cheap programmers should think again. If you think good programmers are expensive, try getting some cheap ones.
Talkback: Have Your Say Message Index:
The Messages: In premise I agree but...As part of the management establishment, I think you've over simplified what CMM is trying to accomplish (or at least what I've tried to accomplish with some of its practices) and left out a couple of inconvenient facts of life with "hero" programmers. The hypothesis that cheap programmers are far from cheap has been proven true too many times to mention and thus I have no argument with. The hypothesis that creating systems and designs that any team member can code within is a management pipe dream and generally a poor investment is less clear to me. Systems that perform and can be maintained over time do not generally fall out of the head of one programmer working alone in a sealed room. In my experience, generally these sorts of systems are well reviewed and understood by peers, who have made contributions to the design and code. This implies that some consistency in the level of communication must occur, be it design documentation, coding standards, test suites, metrics or what have you. This necessarily puts some constraints on our "hero" as she is not free to develop as she pleases, but must have her great idea vetted against not only the rest of her teammates but the constraints of time, money and quality as well. Although the full CMM enchilada is a little more than most shops can or should bear, a certain amount of cross pollination and control is necessary in order for the software to live beyond the life span (generally three years or less for the really talented ones) of the originating hero. To me this is what CMM brings to the table: a consistent set of restraints applied across the team to both expand the life span of the body of work and to provide a degree of predictability to the originating project. Productivity is absolutely lost in CMM development due to the constraints, but at upwards of $300K per man year for good talent on a contract basis, the risk reduction the broader understanding and control CMM gives seems well worth it. Finally to my last point, heroes like new development, they don't want to hang around for maintenance mode. When it comes time to hand the system over to the lesser gods, all of the documentation and review of the hero's work pay off not only for the company, but for the hero as he can move on to greener pastures, without the company tying strangle knots to him to add "one more feature" to his last project. just my .02 -jww Jim Weiss weissjim@hotmail.com Seattle, USA Wed Apr 21 04:40:33 BST 2004 I Agree!! Yes, CMM is just a buzzword. Another ant-CMM stuff here. http://www.pikko-software.com/roller/page/jaredflo/20040306 Jared Odulio jared.jfi@comclark.com Wed Apr 21 10:22:10 BST 2004 Management Perks with Cheap Programmers Since managers may jump from company to company, has anyone tracked to see if the managers who made the outsource decision were around a few years later to face the lousy computer programs that were produced? Or had they already moved on to a new job, with a pay raise based on outstanding recommendations for their cost-cutting policies? Do the concepts of product quality control have any application, or is cheap price promise the prime management motivation (if one can scram before promises confront reality)? Rick brazitis@silverlink.net Seattle, USA Tue Apr 27 06:20:44 BST 2004 another problem The problem is that hiring few good programmers instead of 30 novice ones, scales down a project; there is less to manage and that's not good for a manager's salary. A manager can't be proud of managing a team of 3 programmers (there's nothing to manage). Instead of that he wants a bloated (in terms of management) project with 30 "programmers", a lot of enterprise solutions and meetings and a lot of problems to manage. I've seen such a project where three frustrated nerds did the same project in a couple of weeks in the evenings without all these enterprise solutions. They showed their cheap version, which did the same and they were just ignored by management. Later on they were fired because their department was "outsourced". justus justus@nospam.de de Sat May 01 00:54:20 BST 2004 Are "good" programmers really all that good?? I will be the first person to admit that I am not one of those super programmers that can replace three other coders, much less ten, but I have had experience with a few people who probably think *they* can - and I would assert they can't. Oh yeah, they may be smarter than I am, they may be able to write code faster than I can, and sometimes even better code - but they often can't be bothered to comment their code (much less document it), or even test/debug it. After all, they just proclaim it "finished", and if it doesn't work as advertised, then that is because it just needs a little polish (guess who gets to "polish" their code - it usually isn't them). They *look* more productive this way. Still, I have worked with some good programmers who actually documented their code, tested and fixed the bugs before checking it in, and who did it twice as fast as I could have, maybe even three times as fast, but 20 times as fast? I haven't seen it, and I've worked with some pretty good people. Also, I have never heard a single one of them say they needed less help churning out code - just the opposite. Finally, I have to agree with Jim Weiss - the days of the one man show are pretty much over. A decent team will always have the advantage of differing viewpoints, from which mistakes can be seen. anonymous coward lcb.ng@comcast.net Seattle, USA Sat May 01 06:20:47 BST 2004 hero do what Joe can't do I have meet once a hero programmer: he was maintaining an SQL query engine running on top of several DBMSs. He was not programming 3 times or 20 times faster that average Joe, he was writing software that Joe can't write. He was working 2 months a year for the company, and 9 months for personnal stuff. His direct manager recognizes this special quality and shields him from corporate scrutiny. Yes ADP has good programmers, luckily they don't know it. Jhonn software.reality.egoguerillas@neverbox.com Wed May 05 10:16:43 BST 2004 Grace Grace Hopper http://www.sdsc.edu/ScienceWomen/hopper.html Anonymous person Mon May 10 04:49:26 BST 2004 Definition of a hero programmer I wouldn't regard a programmer that can churn out a lot of code, without a view to maintainability as a 'hero programmer'. Any programmer worth their salt automatically produces clear and readable code, including comments, even if they believe software will only ever be seen and used by themselves. anon coward anon@coward.com Wed May 12 08:24:55 BST 2004 Outsourcing and Hero Programmers I am still trying to understand why everyone thinks that the outsourced code is of a such bad quality? I think software engineers from different cultures are just like us. Some are very good and some really stink. Maybe this is just the good ole' American ego? Let's just step it up and back up our claims! We can definitely do that. If you include the time that is necessary to redesign and refactor a system when major changes are necessary is where you see the large difference between levels of software engineers. A bad design and implementation is horribly apparent then. This, of course, is not obvious to non-technical people (most management) during initial project creation. The idea that management wants a larger group to manage for self-preservation is very interesting. People out for themselves?? :) Steve Terapak terapaks@terapak.com San Diego, CA, USA Thu May 13 17:11:25 BST 2004 good vs. bad programmers It's actually quite simple to distinguish the good and the bad programmers. It's just a matter of testing their abilities by asking them a couple of questions and let them program some stuff. Just ask them how they would implement something like Tic-Tac-Toe in their favorite language or show them some those bad business requirements and ask them what they want to know to start designing or implementing the software. fedor fedor@nospam.net .nl Sun May 16 22:56:12 BST 2004 great article! Marison Souza marisonsouza@yahoo.com.br Brazil Wed May 19 16:38:29 BST 2004 Thanks for saying it!!! Robin thanks for saying it. Keep up the good work. AK gonesail@yahoo.com Thu May 20 22:01:59 BST 2004 Let's face it... Logic, physics, and computers work the same in Nigeria, India, Somalia, EU, and USA. We are all caught in a world "Who's Gonna Work Cheaper" championship, and that's about the only challenge left. Creativity, innovatiove ideas? Don't bother with them. There is a good chance, that somebody is already working on each and every idea you might have, for one tenth of your salary. Once the 1st world living standard gets globalized to the 3rd world level, technical jobs there might get attractive again. Until then, the best thing to to is to seek locally marketable alternatives, forklifter driving, new age healing, pet pshchology, and such. As far as ideas are concerned, take a tip from me, sugar: if you can't sell it, sit on it. mataj Slovenia Mon Jun 07 13:01:52 BST 2004 The value of a programmer and the CMM. Many people outside of our profession don't understand the unique value of each programmer. Most do not understand programming's value as a profession either, and they often devalue programming as hourly labor rather than regarding programmers as responsible professionals more akin to engineers, lawyers, and doctors. Robin started to allude to this fact in pointing out that you can't dump a realtime programmer into an investment banking IT position with no loss of productivity. I believe that this is partly the fault of programmers and partly the fault of those who market them to potential employers. The fact is that programmers have commoditized themselves by boiling their value down to a set of languages, operating systems, and tools they have used with an associated number of years of experience on each. How many resumes and web postings have you produced with this 'mandatory' information? Why is it that headhunters search on these terms, rather than looking at the unique experiences in problem domains you've worked in? Because it is easy! Usually, programmers are hired by other programmers, or by those who have been programmers in the past. Those of you in hiring positions don't have the time to do adequate searches, so you offload this responsibility to know-nothing HR types who can only search for the buzz word of the moment. They don't know that a person with Java/Windows experience may be a better fit for a C++/Unix job by virtue of a great number of other, more subtle, factors. The programming profession is relatively new compared to the others I've mentioned. Attorneys and Doctors really have things figured out, and we should take lessons from them. They control their own profession, and programmers do not. They license themselves; programmers do not. They influence the number of slots at universities conveying degrees leading to certification exams; programmers do not. They organize in professional organizations which demand respect not only from the scientific community but also from government. Software, and engineering organizations in general, obtain technical respect, but wield little power to influence the government or learning institution admission policies. There are few meaningful certifications that are respected by employers. Stop commoditizing yourself! Build or join organizations that can influence the factors leading to commoditization. Find certification programs that are meaningful, get certified, and insist the people you hire get certified. Regarding the CMM, Robin makes a very valid point that no two projects are alike and that CMM doesn't really address creativity or individuality. There are a lot of things CMM does not address, but that does not diminish its value. CMM's goal is for an organization to achieve predictable, high quality results. It also focuses on continuous improvement. These are noble and worthwhile goals. These are all qualities that our organizations must obtain as we are now in a globalized economy, and if we don't do it, someone else will. Our challenge is to do it AND maintain creativity and individuality. We should, as I've tried to say above, honor not only the programming skills of individuals but also their unique skills in a problem domain. At the same time, we must find ways of normalizing the ways in which our work is accomplished in an effort to systematically squeeze out defects, shorten cycle times, and produce meaningful documentation. The most CMM Level 5 certified companies in the world reside in India. That is, in itself, quite an accomplishment. I suspect, however, that these companies have not necessarily found ways of obtaining level 5 status while at the same time maintaining high levels of creativity, individuality, and respect for individual knowledge of problem domains. I have no evidence of this; however, I think it is, conversely, the reason that so few companies in the US have achieved level 5 status. I think we are witnessing a cultural divide. One side has creativity and individuality, while the other has predictable and repeatable processes. The side to find a way to do both at the same time will be the ultimate winner. Clearly there are no absolutes, but the race is on. If you want to keep your job, if you want to maintain a first world standard of living doing the work you love (contrary to the assertion of the previous poster), then find a way to make your organization do both at the same time. Daniel Sterling dan@sterlingtechsoftware.com Tenafly, NJ, USA Sat Jun 26 23:04:40 BST 2004 Positions of well known organizations. My ICCA chapter sent me the following two links on the position of two well known professional organizations on outsourcing and cheap labor, in general. http://www.ieeeusa.org/forum/POSITIONS/offshoring.html http://www.nspe.org/govrel/gr2-4065.asp They also sent this article on the pros of outsourcing (looks like the article was taken down but the responses are still there and very telling): http://www.eweek.com/article2/0,1759,1557019,00.asp Daniel Sterling dan@sterlingtechsoftware.com Tenafly, NJ, USA Mon Jun 28 22:36:15 BST 2004 >Attorneys and Doctors really have things figured out, and we should take lessons from them. They control their own profession, and programmers do not. Doctors can be called to reply to a criminal charge if they work negligently. Programmers do not. > At the same time, we must find ways of normalizing the ways in which our work is accomplished in an effort to systematically squeeze out defects, shorten cycle times, and produce meaningful documentation. The best way of doing the programming is trust between programmer, and employer or investor. I think, that trust is the essence of the problem here. Namely, mutual trust is like mineral oil- once the deposit is pumped out, and turned into cash, it takes about an eon to build up again. And the said commodity seems to be in pretty short supply in the software industry right now. Once the trust and goodwill is gone, normalization and measurement becomes necessary. Fortunately, in programming that's pretty hopeless. Writing programs is like straightening out the entangled thread. There's impossible to tell beforehand how much the thread is entangled, and how much work will be necessary to straighten it. Planning is therefore impossible. Measuring such task would require exactly as much effort as actually doing it. Because there is no way of measuring the productivity of a person doing such job, there can also be no way of impelling, or setting the norms. The only standards, which can be set here, are the lowest possible ones. ... Squeeze out defects!? How nice :-> Alas, guys stupid enough to write bugless, flawless, clear, readable, well documented programs, usually get pink slipped the very moment their masterpieces are finished. In general, writing code without defects is highly unrecommendable from the profit point of view. There are exceptions to this rule, software for space shuttle and such, but they are few and far apart. Programs must have exactly the right ammount of bugs. There must be enough flaws to prevent buyers from living with the current version for more than a year or so, but not as much as to get them to switch vendors. It's similar to car industry. Enormous ammount of research was done there in order to design cars to fail exactly after certain ammount of years and/or miles. Many engine parts are deliberately prestressed for this purpose. You drive a car for five or ten years, and then- poof! All of a sudden, the most expensive parts start to break, everyhting starts to fall apart, and you are forced to buy a new car. >Stop commoditizing yourself! In this business, you are not human, you are resource. If you are not happy with it, tough. World supply of self commoditizing, code cranking morons is endless. In the 99% of cases, they can get the job done. Sad, but true. >I think we are witnessing a cultural divide. One side has creativity and individuality, while the other has predictable and repeatable processes. I'd say it's more like a divide between elite, specialized markets for custom made stuff, and general markets for mass produced stuff. It's like a divide between working on assebmly line, and Formula 1 workshop. In the first case, number of job positions is big, and supply of workforce inexhaustible. In the second, supply of creative, skilled workers is limited, but so is demand for their services. Two different worlds, with one thing in common: fierce competition. mataj Wed Jul 07 15:36:32 BST 2004 cost/quality >> Alas, guys stupid enough to write bugless, >> flawless, clear, readable, well documented >> programs, usually get pink slipped the very >> moment their masterpieces are finished. In >> general, writing code without defects is >> highly unrecommendable from the profit point >> of view. I think this is pretty naive viewpoint - I've certainly never worked (or known of anyone who's worked) at a place where they've been asked, either explicitly or implicitly, to put bugs into software for the reasons you state. Certainly, if I found a programmer doing this, I'd kick his/her arse for making my life harder. I have, however, worked at places where the number of bugs in the software is so high that we've been explicitly asked to get the defect level down to a more acceptable rate. I'm not sure about the automotive industry, as this is outside my experience, but software isn't something that breaks after a period of time - it either works or doesn't work (with a given, potentially complex, input), so I think that, at the very least, your point is a bad analogy. The problem with cheap programmers is that cost is a directly quantative measure - we can save £X,000 a year by getting rid of our top programmer. Quality, OTOH, is (by definition) a qualatative aspect to software. Hence, given a choice between having a £X,000 in your pocket or having the software quality go from "good" to "poor", most companies/managers pick the cash. It's reason very easily about something concrete, like cash but less so about something more vague, like quality. The discussion about CMM L5 companies/teams is interesting - certainly in the case of some places, like NASA, the cost of maintaining very high quality software and an ultra low defect rate is exorbitant - for a number of reasons (Google about it, if you're really interested). For most commercial organisations without bottomless (taxpayer's) pockets, there is a trade-off point, where the quality of the software costs disproportionately more to improve. Hoepfully, new technology and techniques like <insert your favourite buzzword here> come along that help lower this point, over time at least. However, I'd argue that cheap programmers and hence crap software are (and probably always will be) a fact of software development life, for this reason alone. Essentially, this is the argument that software doesn't need to be perfect - it just needs to be good enough to do the job. Generally, I agree with the premise of the article because I think that most companies sadly do fall far too on the "low-cost" side of the cost/quality balance. In my experience, there seems to be substantially more cases of companies developing software cheap verses developing software well. no thank you Thu Jul 08 17:43:53 BST 2004 >I think this is pretty naive viewpoint - I've certainly never worked (or known of anyone who's worked) at a place where they've been asked, either explicitly or implicitly, to put bugs into software for the reasons you state. Is "This is not urgent, we'll fix it when we can spare some time (when pigs fly that is)", or "we'll fix this if and when testers find it" explicit enough? There's no need to ask people to put bugs into software. It's enough to drive them a bit harder, and bugs will come by themselves. >Certainly, if I found a programmer doing this, I'd kick his/her arse for making my life harder. If I'd found programmer fixing bugs that are not supposed to be fixed, I'd kick his/her arse too. >but software isn't something that breaks after a period of time - it either works or doesn't work (with a given, potentially complex, input), so I think that, at the very least, your point is a bad analogy. Software does not break down indeed. It is subject to the laws of entropy, though (http://www.manageability.org/blog/stuff/laws_of_software_complexity). Hardware gets changed every 3-5 years or so, there are new version of operating systems, new versions of compilers, and so on. Programs, which don't follow theese changes, become useless after a certain period of time. They "rot". I'm sure you are familiar with this one: "Oh, well, yeah, that's not too bad, wait to the next version and it'll be fixed". In order to maintain profits, mass produced goods must have limited durability. Mechanical stuff has it built in. With textile, fashion usually does the job. Apart from entropy, durability of software is sometimes regulated by various annoyant features, bugs, and flaws, which force consumers into buying new versions. Ideally, theese things should become unbearably annoyant after a year or two, but not before. If you consider the idea of deliberatly lowering quality of goods too outrageous, do some research about Frederick Sumner Boyd case. Somewhere around the turn of the previous century, he advised disgruntled workers in the silk mill to sabotage silk adulteration process (http://www.local23.org/sabotage/s7.html). Adultaration (or "dynamiting") lowers the silk quality, and drastically shortens it's duration. It costs money, but because it forces consumers to buy silk products more often, it increases silk mill's profits. The phylosophical question then arises: Since silk adulteration is some sort of sabotage- is sabotaging of sabotage a sabotage at all? >Generally, I agree with the premise of the article because I think that most companies sadly do fall far too on the "low-cost" side of the cost/quality balance. They fall where the profit is. Enthusiastically writing excellent software is nice, but nobody will ever manage to pay his bills this way- unless he/she's writing programs for some space probe, of course. But that's about 0.0000000013% of all software written. mataj Fri Jul 09 10:32:55 BST 2004 10-4 I have been in the computer field since punch card days. I cut my teeth on the IBM 1401 with SPS. Now I do the high powered stuff -- even in my retirement. You get what you pay for in this business -- just like in most other business. John Rynes John Rynes honeyhut@aol.com Citizen of, the world!!! Tue Aug 03 18:55:27 BST 2004 productive "the best programmers are up to 20 times more productive than the worst programmers" - this is a tempting proposal, especially if you consider yourself a good programmer, which obviously you do. Here's a different perspective: bad programmers are way more productive than good ones because they don't bother to make a good design before they start coding, they don't think about error handling, they don't do extensive testing or refactoring, etc. It is actually a serious question how to define and measure productivity. Managers want some quantifiable measure, and it is always hard to convince them that making better quality in more time isn't less productive. So I would like to ask: has anybody an idea how to unambiguously measure productivity in software engineering so that quality is adequately taken into account? And how do you measure the productivity of individual team members to conclude that X is 20 times more productive than Y? piglet Mon Aug 23 15:12:16 BST 2004 experienced programmers going cheap I would say that the dot-com boom allowed many inexperienced programmers to get into the industry without adequate mentoring. Thus they attained senior status on the back of doing Java at the right time.. I don't see much evidence of teams bloating in the way described except perhaps in banks - even then they are pretty fussy about who they take on (now) In the subsequent downturn and as outsourcing began to bite I found that entry level programmers had no chance as even graduate positions were targetted by those with several years experience. In certain regions of the UK even highly experienced individuals (esp consultants looking for a safe port in the storm) failed to find anything. I would be interested to hear how people view the market these days. David david dckm1970@aol.com Scotland, UK Mon Sep 06 18:03:41 BST 2004 How about.... Inexpensive Software Architects It has been my experience, that most software companies are now looking to trim the fat off their expensive taste of U.S. based labor, especially after the tech "Bubble Burst". Outsourcing is now more affordable than ever, for those enterprising companies, willing to take their BIZ offshore. It is easy to see how most U.S. programmers are worried about their job-security. Maybe they should be. A top-notch skilled programmer, with excellent English skills, and 10+ years of programming experience can be picked-up for as little as 19,500 per year in India. With the advent of the "Virtual Office", and high-bandwidth VoIP technology, it is now possible to communicate effectively over great distances with clients, or offshore staff. Furthermore, with software programs that manage the development process, streamlining "shared workflow" is very simple. (Fogcreek.com Fogbugz 3.0) When you outsource software companies to handle some, or all of your company's development projects, you can save about 35% upto 50% off the entire development project. If you are business or company interested in taking your project offshore, please visit www.mitrais.com, or call me: +62-8155-8128-196. I am an American software architect with 7 years, "hands on" experience. I live in Bali, Indonesia where I help coordinate offshore contracts to meet their project requirements and deadlines. Lance Davidson <lancedavidson@yahoo.com> Kuta Beach - Bali, Indonesia Lance Davidson lancedavidson@yahoo.com Kuta Beach - Bali, Indonesia Tue Nov 23 18:20:44 GMT 2004 Which is better Java or .net why so hi, I need help on this issue. which is the better one Java or .net .please post u r comments on this .Some people say the future is based on windows and only .net seems to have more future. with regards, adhavan adhavan adhavan_prakash@yahoo.com lafayette, USA Sun Jul 31 18:43:58 BST 2005 Exactly what we discussed over lunch today! It is quite funny how we discussed exactly this phenomenon today over lunch. It is incredible how unproductive a team of mediocre developers can be. Now, the next question. How do you take a team of mediocre developers and get them excited about technology, so that they can grow towards becoming good developers? Maruis Marais maruis@orbiz.biz Auckland, New Zealand Wed Mar 08 02:24:48 GMT 2006 Ehm - Even though this exists since 2 years, I would like to give a short comment to Mataj's statements. (I can't sleep right now, and I need something to do, right.) -Tweaking cars or anything to break down earlier is the most harebrained idea ever. You cite an example from 1902. That's a while ago, and people change (Even some managers do). Companies that try this oh so clever trick are quicker out of business than you can say "knack". If GM continues to build cars that break down, well, Toyotas' don't. -Cheap programmers & Heroes: The best team consists of five people with different backgrounds, high motivation and access to the right learning resources. If they don't know something, they will put all their life into learning it. And they will come up with solutions. Of course, rare talent exists, very geeky people (which can be nice, too) - but the average company can not build on that. -I strongly suggest that some of you people take a course in basic economics, (There is some random guy called B. Bernanke who wrote a good book, which is entertaining, too) so you might be able to understand how business works. Maybe not in every company. But over time in more and more. -1st world to 3rd world living standards: Certain jobs in 1st world countries might get lower salary in the process of globalization, and 3rd world countries standard of living will increase (wages, too), but after a while that has balanced (dunno whether we all live long enough, see post above) out. Then you might earn a lot less in $, € or whatever, but you can buy many things for a cheaper price or hugely increased quality. Cheap car of the 70`s against a cheap car today, anyone? -Argh. Just a guy (if you behave its onkel_mihail funnysign gmx.de) Currently Norway Thu Jun 08 00:57:42 BST 2006
|
||
All trademarks and copyrights on this page are owned by their respective owners.
Stories and articles are owned by the original author.
All the rest Copyright © 1998-2008 Matt Stephens. ALL RIGHTS RESERVED.