Follow Slashdot stories on Twitter


Forgot your password?
Programming IT Technology

Does the 'Hacker Ethic' Harm Today's Developers? 436

snydeq writes "Fatal Exception's Neil McAllister questions whether the 'hacker ethic' synonymous with computer programing in American society is enough for developers to succeed in today's economy. To be sure, self-taught 'cowboy coders' — the hallmark of today's programming generation in America — are technically proficient, McAllister writes, 'but their code is less likely to be maintainable in the long term, and they're less likely to conform to organizational development processes and coding standards.' And though HTC's Vineet Nayar's proclamation that American programmers are 'unemployable' is overblown, there may be wisdom in offering a new kind of computer engineering degree targeted toward the student who is more interested in succeeding in industry than exploring computing theory. 'American software development managers often complain that Indian programmers are too literal-minded,' McAllister writes, but perhaps Americans have swung the pendulum too far in the other direction. In other words, are we 'too in love with the hacker ideal of the 1980s to produce programmers who are truly prepared for today's real-life business environment?'"
This discussion has been archived. No new comments can be posted.

Does the 'Hacker Ethic' Harm Today's Developers?

Comments Filter:
  • Says who? (Score:5, Interesting)

    by seebs ( 15766 ) on Monday June 29, 2009 @04:46PM (#28519465) Homepage

    Hi, I'm a self-taught cowboy programmer. Never took a single CS course.

    I spent ten years on the ISO C committee. My coworkers like my code reviews because I'm thorough and careful. While my code isn't as good as I'd like it to be, the big hunk of my code that we put into our last product release has one known outstanding bug, and it's considered "cosmetic" -- it never impacts the actual output. (And that's for five thousand lines of code I produced in three weeks...)

    I don't buy it. I am a big fan of the "hacker ethic" -- and I see maintainability and code quality as *central* to it. Sloppy work is habit forming. The reason I can type ten-line shell scripts in at the prompt and have them work is that I have worked really hard to be good at what I do.

    So, basically, I don't accept the premise. We used to have offshore coworkers from India, and they were useless. They'd reopen bug reports because the same package failed to build for TOTALLY unrelated reasons. ("TeX is not installed" and "linker error due to frame table full" are not the same bug.) Since then, we started hiring people in China, and actually hiring them as full-time staff, and it works a lot better. They're not all hugely experienced, but they're solid, and they learn. (They even argue with us sometimes, which I'm really enthused about. That's how you get good.)

  • by itsybitsy ( 149808 ) * on Monday June 29, 2009 @04:47PM (#28519485)

    Hackers are those that take an axe and hack down a tree creating a mess in the process including casualties that offend the beauty of solutions.

    Designers go about it systematically applying methods that bring the tree down without a mess or casualties.

    Things like PERL are deeply disturbing to anyone with a sense of design.

    Hacks usually have to be replaced when discovered in production systems that value scaling and reliability.

    Hacks have saved me and I always replace them when possible since they are just so offensive and putrid that shivers evoke pain in my spine.

    Design brings the best of software techniques to bear upon problems.

    Software needs work. Iterative improvement. Hacks might be in there but in time they tend to get removed with designed systems or redesigned systems.

    Hackers are not really programmers as they are to enamored with their hacking skills.

    There is nothing redeeming about hacking, all of it is from the dark side.

  • by hedwards ( 940851 ) on Monday June 29, 2009 @04:53PM (#28519581)
    I have to admit, that I'm skeptical that coders now are any more cowboyish than they used to be. I mean I've read stories about how Bill Gates and Paul Allen used to handle Micro Soft's products early on before they changed the name and locale. Somebody will have to explain to me how today's coders can be any worse than they were.
  • opposite of observed (Score:3, Interesting)

    by treat ( 84622 ) on Monday June 29, 2009 @04:55PM (#28519609)

    My observation is that good American programmers can produce software that is -vastly- more maintainable, efficient, understandable. Easier to modify or extend.

    Mostly this is because they're combining a lifelong passion for programming with some education (formal or not) about software design practices. Foreign programmers on work visas are primarily concerned with making a better life for their family, altering their condition from one of near-poverty to significant wealth. They rarely have a passion for the work, and their only requirement is that they can accomplish enough to get and keep a job, not to excel.

    Foreign programmers who could not get a work visa to come to the US, but work for US businesses remotely for a reduced rate due to the discrepancy in cost of living are usually of the same mindset. But usually they weren't good enough to get a job in the US! More recently, their standard of living can be equal or greater by staying in their country.

    I simply don't know where the Indian or Chinese workers are that have significant skill or a real passion for programming, or computers in general. I have never met ONE in my life, despite working with countless dozens of foreign works on work visas. I have met some from other countries, but usually it is not places that are so poor that huge numbers of people are coming to the US to get a job that changes their standard of living. The exception is the former Soviet states. People from the former Soviet states often bring a passion for computing with them. Probably because they weren't poor in the same sense as someone of comparable income in India.

  • by seebs ( 15766 ) on Monday June 29, 2009 @04:57PM (#28519663) Homepage

    What makes you think creative thinking can't be taught?

  • Really? (Score:4, Interesting)

    by qoncept ( 599709 ) on Monday June 29, 2009 @04:57PM (#28519669) Homepage

    'American software development managers often complain that Indian programmers are too literal-minded,

    Really? I think we've all seen this thing []. If you aren't beign literal minded, you're making assumptions. When you make assumptions, at least some of them are going to be wrong. I spend a lot of time fighting for better defined requirements, because it means I'll spend less time doing rework when what I give my customer isn't what they wanted. The example I always give them is this:

    You tell me college football, if you have possession of the ball and your knee touches the ground, the ball is down, whether or not the player was tackled. I give you a college football game, and the first time you try to kick a field goal, the ball is downed 7 yards behind the line of scrimmage because the holder's knee is touching the ground.

    If you want something, your requirements better document it. Developers with "better practices" understand this. Unfortunately the people who write requirements usually don't.

  • Not just developers (Score:5, Interesting)

    by dave562 ( 969951 ) on Monday June 29, 2009 @04:59PM (#28519689) Journal

    The technology industry has moved beyond its infancy and become a fundamental part of most businesses. I'm a systems administrator and I started working in IT (MIS at the time) when I graduated from high school in 1996. In my childhood, I spent a lot of time hacking phone systems, hanging out at 2600 meetings, and doing all sorts of other not so legit activities with computers. I was interested in whatever systems I could get my hands on, whether it was a System 75 running Audix, a 5ESS/SS7 switch, Linux, Cisco routers, whatever. I read Internetworking with TCP/IP by Comer not because I was in college and had to, but because I wanted to understand what those around me were talking about. All of that development left me with a broad skillset that lacked focus. I developed a very high level understanding of how systems interconnect, and by working for some very good bosses, I developed an understanding of how the systems support the business processes of the organizations I worked for. I'm very much a stereotypical "Jack of all trades, master of none." sort of administrator.

    When there weren't many people out there with an interest in or hands on aptitude with computer systems, people with my skillsets were in high demand. In the small business sector, where companies can't afford separate DBAs, system admins, network engineers and so on, I fit in quite well. In the corporate world, I can't even get a job interview because they are looking for individuals who are highly focused on a single aspect of the overall network. The same thing holds true for developers.

    "Back in the day", being able to write code to get the job done was a mystical science for management types. Skilled coders were in short supply, so people who could hack programs together were employable. In this day and age, anybody can go to any number of colleges or trade schools and learn how to write decent code. Anybody can go to college or trade school and get an MCSE, or a CCIE, or any number of system/network specific certifications. Managers and employers want known quantities. They want developers who are going to deliver predictable code. They want system admins who are going to follow industry best practices.

    The technology industry has grown up. We aren't in the days of "Just make it work" anymore. We're in the days of refining how things work. Best practices have been established. Frameworks for doing things have been established. Companies are just looking for people who can "Make application X do A and B." reliably.

  • Horse Pucky (Score:5, Interesting)

    by Greyfox ( 87712 ) on Monday June 29, 2009 @05:00PM (#28519727) Homepage Journal
    There are just a bunch of really bad programmers out there. Degrees and nationality are largely irrelevant to skill at it. Don't blame "kids these days" or whatever because you're not good at filtering out the bad ones. It's not particularly difficult to spot the good ones, they're pretty enthusiastic about the questions you ask them and the problems you give them when you're interviewing.
  • software engineering (Score:3, Interesting)

    by Deanalator ( 806515 ) <> on Monday June 29, 2009 @05:02PM (#28519759) Homepage

    "...there may be wisdom in offering a new kind of computer engineering degree targeted toward the student who is more interested in succeeding in industry than exploring computing theory."

    Which is why many universities offer software engineering degrees as a more practical alternative to computer science degrees. Software engineering degrees were offered at many of the schools I was looking at back when I started my undergrad in 2002. I was actually annoyed at how many software engineering classes my university crammed into my computer science curriculum since I had no intention of becoming a cube monkey.

  • by cromar ( 1103585 ) on Monday June 29, 2009 @05:06PM (#28519825)

    are we 'too in love with the hacker ideal of the 1980s to produce programmers who are truly prepared for today's real-life business environment?'"

    If only we were more in love! The thing is... the "cowboys" who can't shoot straight (e.g. write scalable, maintainable code) aren't real hackers anyway. It's a lot easier to be able to bang something together with glue and nails than it is to truly hack development. Any responsible hacker is going to know all about best practices, when to break them, and when to find new ones. There is beauty in simplicity as well as in obscure complexity. Whatever. Let the next generation all take classes in SharePoint or some crap like that and the good programmers among us may have even better job security than we had hoped for!

  • by Anonymous Coward on Monday June 29, 2009 @05:13PM (#28519951)

    It's not that it can't be taught - it just takes much more time and patience to teach. With any business, time == money.

    Where I work, we hire for creativity. The programming skills come second as they are much easier to teach (and practice) on the job.
    Of course, most of what we produce is highly visual. So it's a good thing to have a heavy creative tilt.

  • Cowboy Up. (Score:5, Interesting)

    by SoupIsGood Food ( 1179 ) on Monday June 29, 2009 @05:27PM (#28520189)

    When Indian companies come up with globally game-changing software on the same timetable as a Silicon Valley start-up like Facebook or Google, we'll talk. When a Chinese company has the long-term track record of quality and maturity that IBM and Oracle exhibit, we'll talk.

    Until then, the cowboy coder makes better software in less time at the beginning of their career, and matures into a more competent team player as the years roll by and experience piles up. This isn't a weakness, this is why we have an IT industry at all. H1B coders are generally useless until they learn to Cowboy Up... and once they do, there's not really much difference between them and the locals. (I wish more of them would apply for permanent residence and bring their families over. I like immigrants who want a better life, I don't like scabs.)

    Engineers at Honda start out their career working for the racing division, designing high-performance parts. Engineers at the end of their careers are assigned to subcompacts and mini-vans. This is because Honda needs fresh insights and youthful eagerness and excitement, and if the engineer flubs it, the only ones who know are the racing team. More importantly, Honda needs experienced hands who know their craft inside-out and upside-down to engineer the components millions of their customers will be using everyday, and their senior engineers generally appreciate the stability and predictability of a long-term ongoing project.

  • by dballanc ( 100332 ) on Monday June 29, 2009 @05:29PM (#28520215)

    This is the approach that my college took, and I have to say I find it a horrifyingly bad one. One or two courses could easily extend education to cover actual use of tools, and common practices in industry at the time.

    Having personally graduated from a 4 year college with a CS degree with very little real experience is something I found extremely frustrating. I finally came to the conclusion that the lack was primarily due to the educators themselves lacking real-world experience, and happily living in their own little world of academia.

    I do believe strongly in the approach of teaching students how to learn over teaching them specifics and the benifits of a broad education. What irks me, is that it should be possible to do both - but where I went they didn't even offer electives that I could have optionally taken to expand my horizons.

  • by MarcoAtWork ( 28889 ) on Monday June 29, 2009 @05:34PM (#28520281)

    I think you forget one thing, there are no college courses about

    - what to do if a task you scheduled for 6 weeks gets cut to 2 due to somebody in management arbitrarily deciding that 6 weeks "is way too long"
    - what to do if you are asked for a detailed estimate of a 2-3 month long task in an area you are not familiar with 'by the end of today' and that estimate will be binding
    - what to do if your technologically sound solution is shot down 'because this would cost too much to implement, can't you hack something for the next release next week'

    etc. etc. etc.

    If put in a job that rewards creating good quality code, good developers will flourish, if put in a job that rewards 'just hacking something together' then the 'self-taught coder' usually will do better because they won't even have to waste time architecting or really thinking, they'll just take the requirements and run with it, whether or not the requirements make sense and whether or not the resulting product will be mantainable, documented, working, or any combination of the above.

    What the US needs, rather than better schools/programs, is better companies focused on creating quality products, not companies that just because there is a perception that 'coding/coders are cheap, we can also outsource' get by with the absolute minimum of quality the market will tolerate.

  • This will probably get me modded down, but what the hell, i got karma. You want to know the REAL difference between an American and an Indian coder, and why they think of us as "cowboys"? One word: Adaptability.

    Working on this job with a really sweet Indian girl, who was quite happy to be an American citizen now and said she wouldn't go back if you paid her, I asked why does Indian tech support suck. This was after we were all rolling on the floor laughing as she dealt with tech support by cursing them in Hindi when they told her to reboot again. She rolled her eyes and said "it isn't just the tech support, it is the programmers too. I would take one American over a dozen of my countrymen if they have never lived here for any length of time". She then sat down and explained it like this-

    "It is the caste system" she said, "There you NEVER question those above you, ever. if your boss says the sky is purple and 1+2=12 then that is the truth. You never question those above you for any reason. Which works fine as long as it is something that can be written down and followed step by step. But life and computers rarely work that way. They always throw you curve balls and pull weird things that somebody forgot to write down. In those cases the American will "pull a Macgyver" and make it work. The Indian will just be lost, as you just don't do things like that. That is why I am quite happy to be here, thanks."

    So if you want to know why they think of us as "cowboys" there you go. It is because an American will try to figure out a weird problem while the Indian will wait on his/her boss to tell them what to do. Which is fine if you want nice little drones that can't think for themselves, but we just aren't built like that. And I for one am quite happy about that. So call us "cowboys" all you want, but it gets the job done.

  • by Maxo-Texas ( 864189 ) on Monday June 29, 2009 @05:38PM (#28520341)

    It's not so much that it can't be taught as it can be completely squeezed out of the children by the time they reach college age.
    The bar is *very* high in india-- you either pass or you are screwed and may as well kill yourself (as about 3,000 a year do).

    Who wants to be "creative" in that kind of environment- you want to master the material and get the best possible grade. Creativity has no value until you are a grad student anyway.

    Americans tend to overvalue creativity from an early age-- wasting a lot of opportunities to be good worker bees. The result is poorly trained but creative individuals.

    I saw it this way once...

    American tries a thousand ways to draw a fish and finally masters drawing a fish. All along the way they are creatively making variations of the fish.
    Chinese are taught the one perfect way to draw a fish. Once drawing a fish that way is mastered, then they start creatively varying on the mastered fish.

    The sub-masters in China would be less creative while the sub-masters in America would be more creative.

    The masters in both cases are basically equally creative.


    I don't know for sure about Indians. Mainly- they just seem less bright and more "yes men" than they were in 2002-2003. I think the bright ones were promoted and the tremendous demand means that we now have bachelors degree types competing against our bachelors degree types where we used to have their masters degree and doctorate candidates competing against our bachelors degree types.

    So now they are average decent coders-- who are not as creative (because the creative types were filtered out by their culture, schooling system and national exams), more prone to agree to things which are impossible, and (slightly) lacking in communication skills.

  • by Sta7ic ( 819090 ) on Monday June 29, 2009 @05:40PM (#28520369)

    That's when you apply this odd thing called "experimentation". Just take a look at Thomas Edison. He sure as hell didn't sit around waiting for brilliant ideas, he put together a bunch of things, figured out what was wrong with the ones that didn't work, and adapted his next effort based on what he learned.

    If you've always wanted to write music or make art, get off your butt and do it! Re-evaluate what you've done after you've done it. And realize that an "artist" is always their own worst critic, making it prudent to have someone else look at what you're doing.

    "I was never taught to do something good" is no excuse for not trying!

  • by TheGrapeApe ( 833505 ) on Monday June 29, 2009 @05:47PM (#28520469)

    and they're less likely to conform to organizational development processes and coding standards.

    A lot of times, the "Cowboy Coding" is more effective because the "development processes and coding standards" were implemented and enforced by phonetaggers who have never written a productive line of code in their entire lives. Those who are inclined to break them, naturally, are more productive and seem more effective - despite the grumblings of the phonetaggers that they are "unmanageable".

    But, really - Does "management" have any right to blame them? They spent the last decade proving to every developer the idea that if you allow yourself or your work to be commoditized, we will ship you or your job overseas where it can be done cheaper. And "development processes and coding standards" are usually implemented with the intent of "commoditizing", to a certain degree, the work of coding....and you're going to blame the *developers* for rejecting that? Middle management in the US basically *created* the environment that forced developers to either become "Cowboys" or to compete with people making $4/hr overseas.

    Speaking on behalf of coders everywhere - You can take your "development processes and coding standards" and shove it - I'll keep my job and let you grumble under your breath about how I am "unmanageable", thank you.

  • by Anonymous Coward on Monday June 29, 2009 @05:49PM (#28520499)
    My employer's off shore developers generally produce nothing better than "acceptable" and it's generally hard to get them to maintain things. They like to developnew things and don't even like the idea of maintaining their own code.

    But they're dirt cheap. So they have better equipment and more developers than we have in the UK. We're still waiting to get two developers replaced that left. Apparently they think we can replace them without placing adverts.

    To be fair to the off shore guys, the only reason why they develop rubbish (as has been done in the UK too) is that the people coming with the requirements don't have a fucking clue what they're doing. There is a lack of ownership to see the project through once its launched and in general, the low level people have a better idea about technology than management and as a result anyone with any decent skills move on. This goes for the UK and the off shore developers.
  • by Lord Ender ( 156273 ) on Monday June 29, 2009 @05:50PM (#28520523) Homepage

    Sure--and mechanical engineers should just learn the mathematical models of bridge design in school. It's not the school's job to each them case studies and practical skills. They can learn that from experience after the first few bridges collapse.

    (If you missed my point: it is horribly horribly stupid for schools to excuse themselves from teaching things simply because they could be theoretically be discerned through "experience.")

  • by caffeinemessiah ( 918089 ) on Monday June 29, 2009 @06:36PM (#28521053) Journal

    If you are good with technology, why stick around in a country where half of households don't even have toilets?

    Because it doesn't really matter as long as *your* house has one. Metaphorically speaking, if you have the option of making $40k in India -- which goes a LONG way -- and staying at home, living like a king, keeping your social support system, etc. vs. migrating to the states and starting anew for $80k., then a lot of perfectly rational and obscenely talented people will choose to stay there. Money really isn't everything.

  • by MarcoAtWork ( 28889 ) on Monday June 29, 2009 @06:57PM (#28521281)

    lucky you I guess, I have a MS and as much as there were plenty of courses about how to balance things that could be balanced, I wasn't exposed to the 'hack it now, fix it later, assuming there is a later' mentality until I entered the business world.

    In university the cost/benefit analysis always assumed a certain minimum level of product quality, and a certain minimum level of 'fit for consumption'-ness of the end result, therefore cost/benefit estimates tended to have reasonable constraints.

    It's like if in uni you have a cost/benefit analysis between gold plating and nickel plating of your widget, while in the business world your choice is between

    - no coating with guaranteed rusting in a year (but then hey, you sold it, so whatever)
    - make it of cardboard (look, this can't rust!)
    - trying to photoshop a drawing of the widget to make it look like it's been developed, and sell an inferior widget that doesn't even meet the use case with vague promises of a future 'patch' that will fix the customer issues

    when I was in uni I read dilbert for fun, now after 10+ years in the industry the feeling I get when reading it is a lot closer to 'been there done that' rather than 'hahaha, he is so funny, where does he get these ideas from'.

  • by networkBoy ( 774728 ) on Monday June 29, 2009 @07:33PM (#28521705) Journal

    The way we dealt with that was simple (if a bit patronizing). We have a couple "cowboys", myself included. We blaze proof of concept code in whatever the heck language suits our needs for a task at hand. The task is defined as we have these constraints, these goals, and need this data to sift out (this is machine test code). One of us will hack it up in a quarter or two*. Then it is handed off to the test engineering team to make a polished product out of it (usually in C/C++). During this transition we are answerable to the test devs at their leisure and whims, thus if you didn't doc things you'll be in more meetings (and who wants that, when you could be hacking the next shiny thing together).

    It works exceptionally well, as we can react quickly to somewhat amorphous changes to the initial spec, that usually come about as the prototype code is actually run and people realize that "hey it'd be nice to have this", or "that does what I said, but not what I want". We've all encountered this before and it's horribly frustrating when changes like this have to go through committee after committee, and ECOs and all that assorted crap. By doing it as a one man hacker get-er-done these changes become less problematic, some get pushed to the formal re-write, others get implemented quickly. The best part is it basically forces the almost universally needed refactor every product could use, but never gets. The stuff that shows up on The Daily WTF.


    *yes, we get about 6 months to produce properly working code. My last project was about 8 months, 60K lines of perl, 5K lines of C++, and about 4 major changes in architecture, 2 of which were ultimately reverted. In fact this latest one is good enough as prototype that they are not re-writing it and are simply running with it. Downside there is now I have to write _real_ documentation, not just code notes.
    so another couple months writing about 200 pages of usage docs, and 400 pages of API docs...

  • by Anonymous Coward on Monday June 29, 2009 @08:11PM (#28522147)

    More americentric idiocy

    If you are a good Architect, and Master Developer, you do all, including your own "drone work" because you do not see it as beneath you.

    The most spectacular piece of development I ever saw done was by a Pure Mathematician. Peter, later Sir Peter, SwinnertonDyer who wrote, by himself, a compiler for EDSAC Autocode (like FORTRAN 4) in Altas Assembly language for the Titan (atlas 2), it took him 6 dedicated weeks, and had as few bugs as TeX.

    The real truth is that programming is VERYÂHARD and that most patterns, tools, methodologies ... do not really help. I have seen very well structured Assembly, in the Unix .s files in linux and bsd and also in os/360 and massively confused rubbish in C++ and Ruby.

    Note that BCPL, B, C, C++ all came out of Cambridge, England.

  • by Fulcrum of Evil ( 560260 ) on Monday June 29, 2009 @09:20PM (#28522863)
    Last I heard, 30-40k was the average wage for a good developer in india. Perhaps your figure is for call center ops?
  • by dakameleon ( 1126377 ) on Monday June 29, 2009 @09:42PM (#28523041)

    Don't blame the caste system, blame the education system - Indian education emphasizes rote learning, while American education has an element of creative thinking to it. The problem is that many equate the ability to perform in exams with the ability to perform at work in situations that are never out of the textbook.

    This can equally occur in the US, where aptitude in maths and sciences is no guarantee of methodical problem solving. Cowboy coders are good in many ways because they work out how to solve problems from first principles, not following the textbook script.

  • by mrboyd ( 1211932 ) on Monday June 29, 2009 @11:50PM (#28523979)
    I like hackers, self-taught, cowboy or whatever's the name of the month who works for me. They have a tendency to get things done (not related to inbox management bs). Presented with a problem I know they'll come up with a solution, unorthodox maybe but one that works. You can always be amazed at how many different technology a good hacker can understand and use and sometime people like that are key to get a project running. Think someone who can interface between the network team, the dba's, the software people and the PMs using their own language and most of the time with more knowledge in their subject matter than them. The problem with them is that most of them are indifferent to processes and quite bad a polishing their work.

    Non-hackers I need too; people with maybe a far less encompassing knowledge but usually a deeper knowledge in more specific fields; resulting in less ability to come up with original ideas; but the ability to follow through a spec and the tedium of finishing a job -as it was requested- to write decent documentation and to follow a process. With just hackers we would release revolutionary product that just don't work; without them we'd probably still be using VB6 and cgi in perl. I need people who care about the intensity of the gradient of the save button on the settings window. I need someone who can sits and update the spec sheet without trying to develop a software to update the spec sheet for him. I need someone who checks the result of the batch job. Yeah boring but seriously it's crucial.

    I see the "hackers" are a special ops force; good when you need to be fast and ruthless; not good when you need to to be in line with international laws and the geneva convention.

    Now please everyone note that I by no mean want to convey the message that non-hacker aren't good programmers; it's in my opinion a matter of mentality in the way they approach a job not a depiction of skills.
  • by Bob9113 ( 14996 ) on Tuesday June 30, 2009 @02:31AM (#28524905) Homepage

    Does research generate more or less long-run ROI in the corporation than rigor? Is there a place for both approaches? Assuming you have a proficient software engineer of each type, how does the corporation maximize shareholder value with each skill set?

    If he had posed those questions, and maybe troubled himself to make a passing attempt at exploring the answer space, this article might be interesting. As it is, it is a mindless hit piece. Corporations need a balance of free-running and rigorous direction. This is particularly true in the high tech sector, which is far from a done deal. This stuff is evolving at lightning pace; exploration has solid value, as does mechanism. Consider what happens when you rigidly apply best practices in our field; you wind up with a system that is heavily coupled to CORBA, RUP, EJB, MDA, SOAP, and a dozen other zombie acronyms.

    The problem is not research versus rigor, it is knowing how to apply each to appropriate problems. That is supposed to be a management task, but they don't understand our field and so don't know how to let a good horse run. They also do not know how to distinguish a good horse from a gluepot, so they do not trust either. And so management tends to prefer the rigorous engineer -- not because he generates more ROI, but because they understand him better. I must cut this short as I am starting to spin off topic, but I highly recommend reading Peter Drucker's exploration of the knowledge worker [] to see where my point was about to wander.

  • by SQLGuru ( 980662 ) on Tuesday June 30, 2009 @10:00AM (#28527703) Journal

    There is a difference between outsourcing and offshoring. We've got a lot of off-shore resources (and more work seems to be going there). But they are all company badged. With Outsourcing, it's all about the bottom-line (cheapest head available writing the code -- quality isn't even an afterthought). With Off-shoring, it's about cheapER resources but still getting decent quality (one can argue if it's as good or not). My experience is that you need a mix of on-shore and off-shore (with little to no outsourcing) to get quality at lower cost.

"What the scientists have in their briefcases is terrifying." -- Nikita Khrushchev