Project Management

Offshore developers: Focus on comprehension rather than speed

Chip Camden thinks that offshore developers need to stop being code machines and start seeking deep comprehension in their field.
In the discussion about whether you charge by the hour or per day for onsite IT consulting, TechRepublic member Marty R. Milette took me to task for being a "whiny, spoiled, American consultant." The idea that I name my own terms and charge more for onsite work did not resonate well with Marty. It doesn't seem to fit into his economic model of the client/consultant relationship.

He writes: "Every problem has a certain amount of 'pain' or 'value' to the customer -- and THIS is what sets the price point in the customer's mind. This is what determines your compensation (and 'perks'). Not some 'perceived value' you place on your own head."

I absolutely agree. Despite my whiny demands, I guess I'm still at or below the pain level for my clients -- many of whom have been with me for years. I suppose I am spoiled because, thanks to all my great clients, I haven't had to actively look for new business in a long time.

But why is that the case when there are so many offshore developers willing to write software for pennies on the dollar compared to what I charge? The short answer is: because they can't do what I do -- yet.

Speed doesn't equal quality

Permit me to grossly overgeneralize for a minute. My experience with many offshore developers is that they're usually quite bright, highly motivated, and can churn out a ton of code. However, I often see a tendency to emphasize "get it done" to the detriment of "get it done right." A thousand wheels get reinvented rather than constructing a wheel factory. The result is usually something that works as advertised, but it doesn't see to the bottom of the problem, and so it quickly becomes a hard to maintain mess.

I think this approach springs from an urgency for offshore developers to prove themselves by producing a large body of tangible results. Back when I was a green-horn programmer, I used to crank out hundreds or even thousands of lines of code in a day -- but it wasn't particularly good code. Nowadays, I write much less code, but it's code that matters. It's often 10 lines of code that required hours of design. It's the $49,899.95 "X." And it's usually more important for what it teaches than for what it does.

Tips on becoming a code guru

Here's my advice to hungry contractors around the world: seek deep comprehension of your field. Learn to think deeply about each problem you encounter and resist the urge to "just code it." Remember that the first attempt should be a prototype, the second attempt highlights the limitations of your design, and it's usually not until the third version that you have something worth unleashing on your client. Read all you can about different design and programming methods. Even if you never use three fourths of the methods, they'll make you think more thoroughly about the methods you use. Do not just rapidly acquire every résumé bullet you can think of or simply collect an example of every algorithm you think you might need to copy/paste someday.

If even a modest percentage of offshore developers begin focusing more on becoming gurus instead of coding machines, someday I might have enough competition to drive down my rates. From what I've seen, though, I think I'll be able to retire before that happens.

About

Chip Camden has been programming since 1978, and he's still not done. An independent consultant since 1991, Chip specializes in software development tools, languages, and migration to new technology. Besides writing for TechRepublic's IT Consultant b...

94 comments
arvind.rampurada
arvind.rampurada

Thanks CHIP, This is well written and I cannot agree more.

Marty R. Milette
Marty R. Milette

Want to talk about "quality" -- check out the number of software developers in India working in CMM level 5 and ISO certified shops as compared to American and UK ones. In case you didn't know, many of the QUALITY CERTIFICATION programs originated in the US and UK -- so I find it laughable that US and UK developers perpetuate the blanket statement falacy that offshore developers generate 'lower quality' code than local developers when these foreign shops FAR outrank US and UK shops in terms adherence to CMM and ISO requirements. Chip, do YOU carry ANY kind of certification? What kind of guarantee does anyone have that your $200 per hour 10 lines of code is any better than 100 lines of code from a $15 per hour Indian or $20 per hour Russian developer working in a CMM certified shop? Have you ever outsourced a project? If so, why not publish your story so we can learn from it? If not, then why are you even bothering to write about the topic? I've offshored over 20 different projects -- to developers all over the world -- and on average -- the results have been EXCEPTIONAL and I've paid the developers bonuses for the great work. When it comes to CREATIVITY, I'd take a Russian developer any day because they've built their skills having to work miracles with no resources at all. Throwing money, hardware or software at a problem was not an option -- so they HAD to refine their skills to squeeze the most out of what they had. You won't find Russians whining and crying that they can't do their job because some employer won't give them a 50" screen to work on. Of course, I should have expected Tony "I don't need no stinking certifications" Hopkinson to chime in. How about you Tony? Ever outsourced any projects yourself, or have you only 'heard about it'? There are plenty of 'armchair experts' claiming to have cleaned up messes made by offshore developers, but there are just as many cases of people like me coming in to clean up messes left by LOCAL developers. Has anyone bothered to consider that offshore developers do what they are told -- and if they are told to get the job out fast and cheap -- they'll do exactly that? You want someone to blame -- blame the bean counters. If the contract specifies documentation, additional testing, code review or anything extra -- the offshore firms are just as happy to produce it as anyone else. Unfortunately, sometimes the people writing the contracts and specifications should have spent a bit more time awake in class and these things either get chopped out for financial reasons or from carelessness. On a final point, if you plan to write about someone by name in one of your postings -- it would normally be considered "professional courtesy" to at least let that person know.

ehadzipetros
ehadzipetros

I agree: comprehension is the key for on-shore and off-shore developers. Based on my own experience with SAP ABAP off-shore development the sole motivating goal for on-shore management paying the bills is price and proving the concept to management higher up the feeding chain. As for the companies that the off-shore developers work for, they're focused on piling up the hours for the largest number of individuals, unless they're working for a flat fee, in which case they're focused on speedy turnaround. QA is often an opportunity to add layers of bureaucracy and hours. Bottom line: coding is not a mechanical operation that can be safely handled by somebody on the other side of the world. It's about understanding the requirements which is about understanding something of the business and the users and the corporate culture which boils down to understanding the what and the why and not just the mechanics of the how.

$$$$$$$$$$
$$$$$$$$$$

I see "economies of scale" implied, but not stated, in much of your analysis also. I agree, by the way, with your analysis. This occurred to me as very applicable to mdcore's [withdrawn] complaints. [i]Permit me to grossly overgeneralize for a minute. My experience with many offshore developers is that they're usually quite bright, highly motivated, and can churn out a ton of code.[/i] ...and, I would add, tend to be employed by ConHugeCo, which can afford the costs of travel, relocation and/or colocation, because of their scale. For the same reason, they tend more to focus on volume, "innovation" [really just novelty, or even more accurately, the appearance of it to the untrained eye] and alacrity. So, the point I want to make is that the [b]relevant[/b] variable there is not "offshore" but "mega-corp," which do indeed go hand-in-hand for the most part. Nevertheless, the apparent correlation of "offshore" to "code monkey" is spurious; both are correlated to "economies of scale." [i]However, I often see a tendency to emphasize "get it done" to the detriment of "get it done right."[/i] Me too, though thankfully, less often recently. [edit: remove ???]

sonal_goyal
sonal_goyal

I agree completely to what Marty says. I am based in India and work with various programmers all over the world. I do not think that average programmers from offshore countries like India/Russia have lower skills than those in countries like US and UK. Being close to business, programmers in those countries may be able to better comprehend the problems faced by clients. But technically, I do not think there is any gap.

apotheon
apotheon

1. Your appeals to authority in the form of certifications don't prove anything, either way. 2. It's amusing that you take Sterling to task for daring to point out that offshoring tends to lead to developers doing shoddy work, then talk about how developers local to you (in Russia) do better work than those who are, y'know, offshore -- and don't recognize your own hypocrisy and self-contradiction. 3. It's further amusing to see you talk about people who "claim" to do things and have particular experiences, then claim something yourself without any supporting evidence as though you expect everyone to just take your word for it -- and that, only immediately after you invite people to open themselves up to criticism and insinuations of dishonesty by daring them to provide descriptions of their own experiences. 4. Yes, people [b]have[/b] considered that offshore developers do what they're told -- and, in fact, you seem to have [b]completely missed[/b] the bit where Sterling suggests that the blame for poor quality code from offshore developers can be substantially laid at the feet of the idiots who hire them and provide speed-over-quality requirements as part of the project specs. You're attacking him using his own statements as your weapons against straw men that bear little resemblance to anything he actually said. 5. If you can't stand to be quoted and referenced in public, you shouldn't post to public discussion. If he personally informs you of such notice, that's an unnecessary courtesy on his part -- not a social requirement that, having failed to send you an engraved invitation to the new discussion, warrants your criticism and implied insult. I'm particularly baffled by your reaction considering he actually cast your statements in a positive light, which (frankly) must have required some effort on his part.

Tony Hopkinson
Tony Hopkinson

it was this fool here. http://techrepublic.com.com/5208-6230-0.html?forumID=102&threadID=264712&messageID=2511780 And guess what he still hasn't got any certs , or a degree. Doesn't mean he doesn't know what he's talking about though does it? What it means is he can't produce a bit of paper to prove to someone who doesn't that he SHOULD. The real quality fallacy in business and seriously highlighted in software devlopment, is that quality short of enormous competition or legislative demand is not even on the radar. "Armchair expert", yeah right, I'm meant to take that from someone who's spent so long in the classroom, teachers use him as a landmark to direct other pupils about the place.

Sterling chip Camden
Sterling chip Camden

In an open forum like this, it's generally assumed that we can quote one another and respond to each other. If you'd rather not have that link-love, I'll be glad to withhold it in future. Anybody else feel that way? Regarding outsourcing, I'll gladly admit that I have seen some success stories along with the failures. I never said all outsourcing was bad. It all has to do with the expectations placed on that activity. And I agree with you (as have others here) that those expectations are more often than not the primary cause of code monkey syndrome. I have never needed any certifications. My work speaks for itself. IMHO a certification is like a degree -- it guarantees a certain minimum of competence. If someone wants to hire me, they'd better not be focusing on minimums.

Sterling chip Camden
Sterling chip Camden

I used to work for a very sharp guy who thought that he could create the programming environment that would allow fresh-out-of-college newbies to program applications about which they knew nothing. Non-programmer domain experts would feed the requirements to these code monkeys, and the code monkeys would simply translate them into code. Of course it didn't work. The least unsuccessful programmers were those who spent extra time on their own to understand the applications they were programming, so they could talk intelligently with the domain experts and (*gasp*) even with the end users.

Sterling chip Camden
Sterling chip Camden

Yes, the big broker companies promote this concept. "We'll save you a bundle and provide top-quality services," they promise. And because (as mdcore, apotheon, and Tony pointed out) most domestic coders do just as badly for more money, the promise seems to hold.

Tony Hopkinson
Tony Hopkinson

the only person here who's denigrated one group in favour of another is Mr Millette.... It's coping with the 'comprehension gap' where most business' that go for offshore fail. Their obsession with cheap is so great they don't want to believe that it matters. Look at it this way, if you want the best developers where they are from or based won't matter. Cheapest...... It won't be long before, you are screaming about being undercut by the chinese, or by someone who 'testkinged' a cert.... They'll be cheaper than you. It's the business mentality we are attacking, not the people the business employs to implement it.

Sterling chip Camden
Sterling chip Camden

I didn't say that offshore developers were less skilled. In fact, I think they are often better trained than their western counterparts. The article focuses instead on how the market they serve is often (but not always) focused on quick results at the expense of durability. The best of skills can be misused, and often are.

Sterling chip Camden
Sterling chip Camden

I do like to be polite. But really, I was hoping to point out some common ground that I share with Marty here. I do believe that rate is a function of value provided to the client, and this post sought to find the value that justifies the fees that people are willing to pay me.

Sterling chip Camden
Sterling chip Camden

Yeah, that's a misplaced metaphor all right. Rather than being the Armchair quarterback, you and I are more like the players who learn the game by playing it.

$$$$$$$$$$
$$$$$$$$$$

... you have my blessing to cite any of my published work in your own. I will take it as I would take such citation in a printed scholarly work: as the sincerest form of compliment. I don't want to take sides because of the obvious ill-will, and because I have barely glanced at one of the posts -- not threads, posts -- cited in your opening post here: what you wrote looked to me like an analysis of the [u]perception[/u] that offshore = low quality rush job, and some helpful tips to those workers on overcoming that [u]perception[/u] and earning more money. You may or may not have given Mr. Milette valid cause for offense earlier, but in this thread, I see nothing that I could construe as offensive. On the contrary, I think that if I was an offshore programmer reading your article, I would take at least two of your assumptions -- implicit, but pretty evident to me -- as complimentary. Being a beginner as a programmer, and having written poor code that was worse because of being in a hurry, I did read your article that way. First, that the quality difference is a result of your [u]learning[/u], and that others can learn the same thing. "I think this approach springs from an urgency for offshore developers to prove themselves by producing a large body of tangible results. Back when I was a green-horn programmer, I used to crank out hundreds or even thousands of lines of code in a day ? but it wasn?t particularly [i]good[/i] code." That has been my experience too, Absolutely! And like you, I'm talking about my own experience, not projecting. I have written lousy code, for exactly the reason that I was in a hurry. "Being hurried" by an employer may be a valid explanation, but it doesn't make the code any better. I don't have enough experience to offer any tips to other coders, except to read your articles, and Chad's and Vincent's, and based on what I've seen so far, Michael Kasner's. "However, I often see a tendency to emphasize 'get it done' to the detriment of 'get it done right.' A thousand wheels get reinvented rather than constructing a wheel factory." That likewise assumes, not that we lack capability, but that they need to make a subtle change, to take their time in the short term in order to save time in the long term. As I often put it, "slow down, you'll finish sooner." If lower cost is a factor in hiring, it stands to reason that it will be a factor in the workplace also, so offshore workers will be more directly or more vocally or more emphatically or more repeatedly subject to the pressure to do it fast, and less likely to be reminded to take the time to do it right. I [b]can[/b] state from experience that where offshore labor is employed [b]because of cost[/b], the culture is one where cost of labor-hours is exaggerated beyond cost of errors committed because of time pressure. It isn't necessarily that way with every company that uses offshore labor, but it certainly is, where I've worked.

Tony Hopkinson
Tony Hopkinson

"Better not be focusing on minimums". Nice a good way of putting it, I usually go with "I wouldn't get out of bed for that", but that's a bit more professional.

Tony Hopkinson
Tony Hopkinson

on four seriously bad assumptions. The requirements are known The requirements are understood The requirements are communicated and last bit not least they won't f'ing change during the life time of the project. By the time one of us could get a design written out in some sort of psuedo description we could have coded the thing as well. I will say if you are seriously anal about the process it can work. You can end up with a really well documented over budget and late delivery that no longer does what the customer wants. It's back to waterfall isn't it? Personally I would n't describe the guy as sharp, if fact at best I'd describe him as ignorant.

apotheon
apotheon

Treating coders as commodities, rather than talent and resource, is what creates the problem of hiring bad domestic coders that compare unfavorably to offshore coders (because the major difference is price) in the first place. If accountants weren't the ultimate arbiter of developer value -- if programmers were treated as internal value generators rather than judging them by the standards of cost accounting -- the emphasis in hiring would shift, and good developers would be (rightly) valued more. Treating programmers as commodities (and IT in general as overhead costs) just guarantees that the quality of the code is ultimately treated as nothing more important to business policy than the weather. . . . and, predictably, something that is in fact entirely under the control of the business decision-makers ends up being left to the vagaries of chance, with a definite bias toward poor quality that can materially damage the company's bottom line.

Tony Hopkinson
Tony Hopkinson

and work in Lancashire, so I go through Yorshire twice a day. Some of those real ales go through me just as often. :p

Sterling chip Camden
Sterling chip Camden

Yorkshire, eh? Been through there twice -- the best part for me were the real ales.

Tony Hopkinson
Tony Hopkinson

But I like to be seen as a forthright in yer face no nonsense yorkshireman. I'm comfortable with it. People who don't like it, well they can **** off. :D :p

Sterling chip Camden
Sterling chip Camden

We wouldn't learn anything without them. How one goes about voicing them says a lot more about the speaker than about their target.

Tony Hopkinson
Tony Hopkinson

You know, the unqualified hacks. Tony "I don't need no stinking certs" Hopkinson.... I have insulted you and I will continue to do so every time you, by word, deed or intimation put across that I am failure lacking in drive and intellect because I don't have certs or a degree. If you want this to change, then by all means stop doing it. The only references to you I've made in this thread. Were to your implication that Mr Camden and I don't know what we are talking about because we aren't 'qualified', and to the fact that I've disagreed with you in the past. One is there in your post as plain as can be, the other, well the only people I haven't disagreed with at some point are those that I've never interacted with in any way shape or form.

Jaqui
Jaqui

the lazy, spoiled one. :D I think Tony poked at the person with only reading your name in the post it was replied to. The person he was responding to was ripping apart the original blog post, rather than your response.

Marty R. Milette
Marty R. Milette

And which group would that be that I have 'denigrated' Mr. Hoppkinson? I find it interesting that someone criticizing 'denigration' is the same person who, in previous postings, has used the terms "muppet", "propellor-head", "overeducated idiot" and other equally colorful ones to describe people or groups who didn't side with their own personal views. Instead of launching personal attacks -- why not try to ADD VALUE to the conversation. I know it takes more thought and effort, but I have seen you make some very lucid posts in the past and know that you have it in you if you care to make the effort.

apotheon
apotheon

. . . since you're the one most taking offense no matter what Sterling says.

apotheon
apotheon

There are people who will find a way to take offense no matter what you say.

$$$$$$$$$$
$$$$$$$$$$

It seems to serve your friends better than your enemies, so I suppose that isn't that one rule that has zero exceptions.

apotheon
apotheon

I have a hard time taking that advice, too.

Sterling chip Camden
Sterling chip Camden

Wise advice. But, you know us bloggers, always looking for something interesting to blog about. And judging from the comments in this discussion, I'd say at least a few people find it interesting.

apotheon
apotheon

"[i]I was hoping to point out some common ground that I share with Marty here.[/i]" I think you did well -- and did what I like to think I would have done. I'm just dismayed that Mr. Milette found it necessary to treat your politesse as though it were character assassination and to lash out as a result. "[i]this post sought to find the value that justifies the fees that people are willing to pay me.[/i]" On one hand, I'm inclined to say you've done well in this regard, regardless of whether Mr. Milette is willing to meet you halfway. On the other, I'm reminded of Elbert Hubbard's words: "Never explain -- your friends do not need it and your enemies will not believe you anyway."

Sterling chip Camden
Sterling chip Camden

Crack dealers would be the last people to "open source" their recipes. They have a financial motive for encouraging widespread use while keeping the details of production private.

$$$$$$$$$$
$$$$$$$$$$

Whose awareness of drugs do you expect would be greater than your local crack dealers'? Open Source crack recipes and ingredients ... sorry, am I abusing the soap-box? [i]The idea of vendor certs is about as clever as putting your local crack dealer in charge of a drug awareness campaign.[/i]

apotheon
apotheon

"[i]The idea of vendor certs is about as clever as putting your local crack dealer in charge of a drug awareness campaign.[/i]" That's a great way to put that.

Tony Hopkinson
Tony Hopkinson

value that a professional gets out them. Their value to a business (not one involved in certs), is negligible if not -ve. The idea of vendor certs is about as clever as putting your local crack dealer in charge of a drug awareness campaign.

apotheon
apotheon

I've taken issue with the assumption that certs have any value. I have a few certs -- and they're worthless. The article to which Sterling linked makes it seems like certifications used to be worth something, but now they aren't. That's not really true, though. Certifications were [b]never[/b] a guarantee of value. They just used to enjoy a fortuitous statistical concurrence with value. Eventually, that went away. There's nothing in the concept of a certification in general, or in the design of any certification in particular that I've ever seen, that actually excludes the incompetent.

Tony Hopkinson
Tony Hopkinson

just with the argument that they can be safely substituted for value......

Sterling chip Camden
Sterling chip Camden

... you've taken things the way I intended them, and offered some excellent insights of your own. "Slow down, you'll finish sooner." I'll remember to use that one.

apotheon
apotheon

"[i]I don't have enough experience to offer any tips to other coders, except to read your articles, and Chad's and Vincent's, and based on what I've seen so far, Michael Kasner's.[/i]" I appreciate the recognition of my efforts. I'll continue to endeavor to be worthy of it.

Tony Hopkinson
Tony Hopkinson

one place waterfall can and does and in some ways must still work, is in industrial control applications, bit off the beaten track for most though that. If the problem is suitable, I've always been a big fan of spiral, it's agile enough to keep the customer happy and formal enough for both sides to feel secure.

Sterling chip Camden
Sterling chip Camden

The only time project requirements don't change is if the project is trivial or requires no research. What I've seen work tolerably well is a modified waterfall, where the requirements are laid out up front, but the ability to change certain parts of them as needed is stated up front. In projects that are highly research-based, that's most areas. Then you get to billing. I have sometimes quoted fixed price -- but only for projects where the scope can be well-defined. Most of the projects I work on are highly research-based, so the scope is unknown until well into the design. If my clients want me to explore these unknown regions, they have to be willing to pay me by the hour.

Tony Hopkinson
Tony Hopkinson

Waterfall and Agile are both formal methods. Theoretically RAD was a formal method, it turned into QAD, which is about as informal as you can get. However it could be made to work given very very close cooperation between developer and client. Unfortunately rapid application development is seen as informal, and generally it's taken to mean no documentation. It does make an attempt to reduce the quantity of documentation required but not the quality. Most particularly in house software departments are now RAD, there is little to no formal requirements analysis, design documentation, test plans.... Those who've gone for outsourcing as cheap have not addressed this lack. So you are right, if you want to outsource, (offshore is irrelevant), you can't amble about assuming they know what you want. The only way to do it, is to dot the i's and cross the t's, but that isn't rapid, it isn't seen as cheap and the first two casualties of any IT project that's struggling for resources are Documementation and Quality. Given the prime directive is cheap struggling is a given. So you go formal waterfall, or formal agile, based on the type of work you want done. That basis should rest on how strict you are going to be with the scope, how clear you are on what you want, and how much effort %age wise the first useful deliverable could be. There's no right answer, there are howvere a lot of wrong ones.

Marty R. Milette
Marty R. Milette

An interesting note about a lot of offshore and outsourced development is that, in order to do it SUCCESSFULLY (ie. Make a profit.), the requirements MUST be known and there MUST be a good specification in-place before the first line of code is written. Fail to plan -- plan to fail. Tony's example of 'bad assumptions' actually demonstrates the differences between a 'professional' and a 'hack' -- or more politely, the difference between using formal vs. informal methods. It isn't even just a matter of software development -- it represents how contractors run their business. How are they handled differently... Hack: "The requirements are never known or understood in advance -- so let's head to the keyboard and start coding. We don't need to worry about any existing systems because they were probably done badly and we don't want their bad work to interfere with our good work. We only work on a 'time and materials' basis. We don't offer fixed price because the client always changes their mind. We know what the client needs better than they do anyway..." Pro: "We have worked with the client to analyze and document their requirements, we have studied their existing systems and know how to integrate with them. We have a contract in-place that specifies a fixed price for the base product, payment based on staged deliveries and an hourly rate that covers any changes desired by the client beyond the defined scope. Everything will be documented -- documentation is part of the contract." An unfortunate attitude in the industry is that software development is an 'art' rather than a 'science' -- while there is certainly a need for 'creativity' -- that does NOT mean running to the keyboard to start coding based on a 5-minute conversation with the client and some half-baked assumptions.

Tony Hopkinson
Tony Hopkinson

They are a bit rarer on the ground nowadays (at least in the UK), but I have workd for people who's tech skills were great, but very badly applied. Learning when to stop, and when to drop a bad idea, is a key skill for developers.

Sterling chip Camden
Sterling chip Camden

As a programmer himself, he was quite good. But he never really understood the people part of the equation.

Sterling chip Camden
Sterling chip Camden

Good point, even if your explanation of benefits is simplistic and somewhat imprecise -- savings are savings.

$$$$$$$$$$
$$$$$$$$$$

That, and the unlikelihood of "accountants to the rescue" of programmers. Anyhow, I wasn't even thinking of subtleties like [i]quality[/i] of programming, either. The difficulty of documenting even the cost savings of doing the same volume of business realized by the [i]existence[/i] of programming vs no programming ... it would be a heckuva a programming chore, even to do a lousy simplistic attempt. But a programmer, after doing the work, can pretty confidently say things like "My work is allowing task X to be done Y% faster, or to be done at all," then look up the costs & savings: self-advocacy.

Sterling chip Camden
Sterling chip Camden

... is that it's difficult to quantify the costs and savings associated with the quality of programmer -- even more difficult than assessing the quality of the programmers themselves.

$$$$$$$$$$
$$$$$$$$$$

...or higher standards for accountants? [i]If accountants weren't the ultimate arbiter of developer value -- if programmers were treated as internal value generators rather than judging them by the standards of cost accounting -- the emphasis in hiring would shift, and good developers would be (rightly) valued more.[/i] Alternatively, if accountants were expected to apply the sum of their knowledge of microeconomics rather than only their CPA ledger craft, the revenue not lost by lacking the contribution of programmers, and the expenses not incurred because they did pony up for those efforts up front would at least make programmers look like more desirable commodities. As I write this, it's clear to me that only self-advocacy will get that job done. Accountants will tend to emphasize the importance of the profession accountancy, as-is, with only few exceptions such as exist in any profession. [i]Treating programmers as commodities (and IT in general as overhead costs) just guarantees that the quality of the code is ultimately treated as nothing more important to business policy than the weather.[/i] Yes, we tend to value our jobs no more than they're worth, and some of them are not worth very much.

Sterling chip Camden
Sterling chip Camden

... if you have to pay the price yourself to fight the code monkey system. On the other hand, if you do provide real long-term value, then your abilities should come to be appreciated -- at least, that's the theory.

g.salakirov
g.salakirov

I assume it's not just the attitude towards the coders. It's more like the way people try to do business. Most just take the factory patterns and try to fit the IT in there. And that wouldn't be a big problem if they didn't takes an over-ambitious idea and tried to do it in a low budget scheme. It's just too wrong. In the end , if you decide to do a decent job, you get stuck with the good intention of delivering a well-done work, and a tremendous over-time on the back...