×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Coders, Your Days Are Numbered

timothy posted about 5 years ago | from the yes-but-in-what-base dept.

Businesses 305

snydeq writes "Fatal Exception's Neil McAllister argues that communication skills, not coding skills, are a developer's greatest asset in a bear economy. 'Too many software development teams are still staffed like secretarial pools. Ideas are generated at the top and then passed downward through general managers, product managers, technical leads, and team leads. Objectives are carved up into deliverables, which are parceled off to coders, often overseas,' McAllister writes. 'The idea that this structure can be sustainable, when the US private sector shed three-quarters of a million jobs in March 2009 alone, is simple foolishness.' Instead, companies should emulate the open source model of development, shifting decision-making power to the few developers with the deepest architectural understanding of, and closest interaction with, the code. And this shift will require managers to look beyond résumés 'choked with acronyms and lists of technologies' to find those who 'can understand, influence, and guide development efforts, rather than simply taking dictation.'" Update: 04/04 19:52 GMT by T : InfoWorld's link to the archived version of the story on open source development no longer works; updated with Google's cached version.

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

305 comments

This is extremely old news. (3, Interesting)

Jane Q. Public (1010737) | about 5 years ago | (#27459571)

Proponents of Agile development and similar philosophies have been saying exactly this for many years now. Where have you been?

Re:This is extremely old news. (4, Interesting)

ushering05401 (1086795) | about 5 years ago | (#27459641)

The subject is being revived by the current economic situation, so not as stale as one might think.

Re:This is extremely old news. (2, Interesting)

julesh (229690) | about 5 years ago | (#27459651)

I wouldn't say agile development as a field is stale; it has been gradually attracting interest over the last 10 years, and is more popular now than ever. Yes, this kind of thinking might help it along. But it doesn't really _need_ that help.

Re:This is extremely old news. (1)

Jane Q. Public (1010737) | about 5 years ago | (#27460387)

I'm not saying it's stale at all... in fact that is part of my point. Agile is still quite popular and well. And the message hasn't changed. Therefore, author just wrote about this stuff as though he thought they were original ideas. They aren't.

Repeat: where has he been?

Re:This is extremely old news. (1)

Hognoxious (631665) | about 5 years ago | (#27460889)

Agile is so last year.

Re:This is extremely old news. (3, Insightful)

ShieldW0lf (601553) | about 5 years ago | (#27460967)

Agile is about keeping coders dumb by not allowing them to look more than two feet in front of their nose. It's about protecting managers from being cut out of the decision process entirely. Which they should be.

As for the actual article, seems to me that it's the managers whose days are numbered. Coders who have people skills will become managers, coders who don't will remain serfs, and managers who have no technical skills will become unemployed. It won't happen overnight... some existing businesses will continue to employ those managers. But that choice will kill those businesses, because they're basically putting blind men in charge. It'll take time though...

Re:This is extremely old news. (1, Insightful)

Anonymous Coward | about 5 years ago | (#27461019)

A whole hell of a lot of managers are managers because they can kiss ass, and not because they can manage. If and when their boss realizes this the #2 ass kisser then becomes managers..rinse and repeat..news at 10.

Re:This is extremely old news. (0, Flamebait)

thethibs (882667) | about 5 years ago | (#27459891)

Open source development is not Agile. One of the critical activities in Agile development is paying some attention to the users.

Re:This is extremely old news. (4, Insightful)

EsbenMoseHansen (731150) | about 5 years ago | (#27459953)

Open source development is not Agile. One of the critical activities in Agile development is paying some attention to the users.

Actually, open source developers do. Sometimes, it's just that the users are themselves.

Besides, Agile isn't about paying attention to the users per se... it's paying attention to the people who the payer wants to enable. Again, in the open source world, that might well be the developer himself (paying in time, not money).

Re:This is extremely old news. (3, Interesting)

SerpentMage (13390) | about 5 years ago | (#27460071)

I don't agree here...

As Eric Raymond says, "scratch one's itch" does not imply listening to users.

Put it as follows. We all drive cars, but using scratch one's itch it implies that we are all mechanics as well. And that is not the case, though it can be said that all mechanics do drive cars.

What the article is getting at is that you understand the user that you are empowering. In my case it is being able to understand the formulas and mathematics of the trader trying to define a trading system.

Re:This is extremely old news. (2, Insightful)

EsbenMoseHansen (731150) | about 5 years ago | (#27460205)

I don't agree here...

As Eric Raymond says, "scratch one's itch" does not imply listening to users.

Put it as follows. We all drive cars, but using scratch one's itch it implies that we are all mechanics as well. And that is not the case, though it can be said that all mechanics do drive cars.

What the article is getting at is that you understand the user that you are empowering. In my case it is being able to understand the formulas and mathematics of the trader trying to define a trading system.

The main difference between the open source you're thinking of and the user situation is that these user's are actually willing to pay. Thus, any itch they have will the developer's itch, since the developer want them happy. Of course, for this to work, user happiness would need to actually figure in the bill payers success criterion, which is surprisingly often not the case. I'd argue that the developers would do themselves a favor making sure that it does, though.

Still, for pure open source (scratch you itch) type of open source, the user (=developer) is listened to. Indeed, that does mean that everyone who is not a mechanic is not a user --- because everyone who is not a mechanic does not pay (in time).

Is it clear now? Not entirely sober, so if I'm not I apologize.

Re:This is extremely old news. (1)

Jane Q. Public (1010737) | about 5 years ago | (#27460419)

"Open source development is not Agile. One of the critical activities in Agile development is paying some attention to the users."

I did not state anything, anywhere, that would contradict this. So who are you replying to? What's your point?

Re:This is extremely old news. (3, Interesting)

HangingChad (677530) | about 5 years ago | (#27461103)

Where have you been?

Same question crossed my mind. The last place I worked, coincidentally a Windows shop, was rife with bureaucratic decision making and process for the sake of process. Tasks that could be accomplished for thousands and take weeks ended up taking years and costing millions. The ironic justification for all the process was that the customer did not feel the old agile environment was providing good value for their development dollars. So they took the vague suspicion and turned it into a massive reality.

The new contractor manager brought in an army of unproductive people. Including one with the spiffy title Configuration Control Manager. I never did figure out exactly what she did, other than act bossy, look stressed out and pretend to be busy all the time. Busy digging sand. They spent money on Rational licenses but not on training and no one ended up using it. Tried to fit development into a process that lost contact with the actual application users. They brought in five people to maintain an application built by two, instead of keeping the two who built it. What made this mass insanity more than passing amusement while I looked for another job was they were squandering taxpayer dollars. It was Iraq for IT.

The days of massive IT development projects are over. They've actually been dead for several years but like a zombie those massive projects still limp aimlessly across the IT landscape looking for additional funding blood.

I agree totally... (3, Funny)

rlanctot (310750) | about 5 years ago | (#27459585)

...let the inmates run the asylum. I for one welcome our monkey-poo-flinging overlords!

How about the model of development (2, Interesting)

antifoidulus (807088) | about 5 years ago | (#27459611)

where links are checked before they are submitted/published? Or are you just relying on the open-source crowd to tell you that you get a 404 when you click on the 2nd link?

So it helps to be.. (5, Insightful)

Gorobei (127755) | about 5 years ago | (#27459613)

So, I might do well if:

1) I can actually communicate with the people that are paying me.
2) I can write code that doesn't suck.
3) I actually understand the business needs for the code I'm writing.

Wow. I'll be much more effective now. Thanks.

Re:So it helps to be.. (4, Interesting)

bigman2003 (671309) | about 5 years ago | (#27459967)

Sadly, the HR departments of the world have no understanding of this. All they care about is matching up the acronyms and buzzwords.

I've been turned down for jobs because of this bias by the hiring group.

"What is your greatest strength?"

My method is to understand the business process, communicate with users, and develop code to achieve the business goals.

"Oh, we're looking for a senior advanced journeyman JAVA coder."

Well eff me. Offshore the job and write me a letter when your system doesn't do what you wanted it to.

Re:So it helps to be.. (4, Insightful)

Gorobei (127755) | about 5 years ago | (#27460101)

That's why we don't let our HR department do anything more than post ads, collect resumes, run background checks, type up offer letters, deal with lawyers, and handle workplace issues.

If you let these people get their well-meaning tentacles into your business, you are screwed. These people are the code-monkey version of management: willfully proud of knowing nothing about the actual business needs, and inordinately satisfied with their mad HR skills. Only thing worse than an HR "specialist" is an MBA who works on his MBA skillz rather than learning the business he is being paid to support.

We flushed out a lot of the middle-management parasites twenty years ago. Now they seem to be back with new job titles.

Re:So it helps to be.. (1)

Z00L00K (682162) | about 5 years ago | (#27460659)

I would say that your list should be the other way around and the most important factor is to understand and communicate not with the people that are paying you. They are often just accountants and similar people with little insight in how the customer actually behaves.

The essential point here is that if you can understand the need of the customer really well then you are already ahead of the crowd. Every customer has their own semantics, business language and methods no matter how similar their products are to their competitors products.

If you can't understand the customer you can produce something completely and utterly useless or even something that's harmful for the customers business. That regardless of how good code you write.

But writing good code is of course also important. And if you select the right languages you can get a lot of help on the way to write good code. For Java you have FindBugs [sourceforge.net] and a lot of other tools.

And if you can communicate with the people that are paying you it's an added bonus, but if they consider you a grumpy and obnoxious nerd that still is able to do a good job and actually takes good care of the customer you may have your ways. A satisfied customer is good for the business.

And even if you don't directly communicate with the customer in day to day work it's not wasted time to actually try to understand their case. Don't be afraid to check out what they actually do, and get a sense of their situation. Most customers aren't starting from zero, but have a long history of how things are done.

But be very careful with cases where the application requirements are passed through several layers before reaching you as a developer because that is How Shit Happens [fortunecity.com].

Either trivial or bullshit (4, Insightful)

azgard (461476) | about 5 years ago | (#27459633)

What he argues is either trivial or bullshit. I don't understand what he says, to be honest, so there are 3 possibilities:

1. He says that everybody needs to learn communicate. That's trivial. Everybody, even manual workers, need to communicate. You can excel, but if you cannot cooperate, you cannot work in modern society.

2. He says that communication, not other skills, is where real money/power is. This is also trivial. To scale beyond the abilities of a single person, you have to control other humans, and for that, you need people skills more than other specific skills.

3. He says that the U.S. economy in the future won't need any people with technical skills, only managers, as technical skills can be outsourced. This is bullshit, as the U.S. is going to experience the hard way in the upcoming years.

Re:Either trivial or bullshit (4, Insightful)

julesh (229690) | about 5 years ago | (#27459725)

1. He says that everybody needs to learn communicate. That's trivial.

Trivial or not, there are many so-called "professional" programmers out there who don't seem to understand it. They think their job is to produce code and avoid communicating with others as much as possible. Witness the common reaction to the idea of pair programming: "it'll disturb my concentration... it's hard to hold the details of your coding in your head if you're talking to someone". Well, frankly, you need to be able to communicate those details, so you _should_ be able to talk to somebody about the coding while you're doing it. The focus is on the implementation, not the communication. It should be the other way around.

3. He says that the U.S. economy in the future won't need any people with technical skills, only managers, as technical skills can be outsourced. This is bullshit, as the U.S. is going to experience the hard way in the upcoming years.

Did you read the same article as me? I seriously don't see where it says this. What it says it that lead-from-the-top teams where jobs are parcelled out by an architect with a vision and are implemented by junior programmers will go the way of dinosaurs; it says that everyone is going to need to understand the whole product they're implementing it, the business reason why it's necessary, and to interact with the eventual users of the system to ensure that what they're implementing is the right thing.

This isn't news to some of us, but there are still a lot of people out there who don't seem to understand this.

Re:Either trivial or bullshit (5, Insightful)

phantomfive (622387) | about 5 years ago | (#27459887)

Witness the common reaction to the idea of pair programming: "it'll disturb my concentration... it's hard to hold the details of your coding in your head if you're talking to someone".

Yeah right, that's just the reaction on the outside. On the inside the guy is thinking, "He wants me to do pair programming? He's an idiot. Maybe I'll give him tons of reasons and he'll go away." If you have decent programmers, pair programming is a waste of resources. Much better to have team programming, where each person is working on the different parts of the same project. Then when you have problems, you can discuss them with your partner, not on every single line (should we use a while loop or a for loop here?)

Incidentally, he is right. When I code, I don't think in words, I think in code. If someone speaks to me while I am coding, it can take a second for me to get back into English mode. A similar effect happens when I'm thinking in Spanish and someone unexpectedly says something to me in English. Or when I am playing the piano and someone talks to me.

And for the record: a few years ago there was a study published in Communications of the ACM that showed while pair programming is more efficient than a single solitary programmer, it is not as efficient as two programmers with two keyboards. FYI.

Re:Either trivial or bullshit (5, Insightful)

Anonymous Coward | about 5 years ago | (#27460453)

I'm sorry, but as someone who has recently been exposed to pair programming I can say you're talking out of your backside. If a programmer can't deal with pair programming them they're a very poor programmer. Pair programming is about getting together, thinking and knocking out some code that both programmers agree is the best solution. If you can't do it then it's likely that your ego is taking over and you're ignoring better solutions.
Two decent programmers sitting together pair programming will set out some good, robust code with a lot less bugs as the other is pointing out problems as they go.

I'd suggest that you're a poorer programmer than you think and that you should rethink how you go about problem solving.

Re:Either trivial or bullshit (3, Interesting)

AuMatar (183847) | about 5 years ago | (#27460945)

As someone who has done pair programming- you're wrong. Wen I have to constantly talk and discuss my work while I'm thinking my output falls by more than 50%. On top of that, almost no bugs other than trivial spelling bugs are caught by the pairing process- the type of bugs that the compile catches anyway. Pair programming doesn't work.

There are only two situations in which pairing makes sense. One is mentoring- an experienced dev trying to train up a young engineer. The training for the young guy will speed up the learning process and be worth the temporary loss of productivity to the older programmer long term. The second is debugging obscure issues, where it may take multiple people's knowledge of the code to solve it. In any other situation, you'll get less than half, usually less than a quarter of the work you'd get out of having two programmers work independently.

Re:Either trivial or bullshit (1, Insightful)

Anonymous Coward | about 5 years ago | (#27461065)

So you're only catching trivial bugs? Sounds like a communication problem where the other person doesn't understand what you're doing, or not critically thinking about the problem from another perspective... and hence is only looking for trivial spelling errors.

Re:Either trivial or bullshit (5, Insightful)

Have Brain Will Rent (1031664) | about 5 years ago | (#27460461)

And for the record: a few years ago there was a study published in Communications of the ACM that showed while pair programming is more efficient than a single solitary programmer, it is not as efficient as two programmers with two keyboards. FYI.

It's much older than that - IIRC "The Mythical Man Month" first formalized the idea that N programmers do not produce working code N times as fast as 1 programmer, and that's essentially what is happening with paired programming.

The real problem was discussed long ago in "Programmers and Managers" by Kraft. Two skilled programmers operating independently will indeed produce good code faster than two programmers paired. The problem lies with the idea that there is a large supply of "skilled" programmers. There aren't and most of software development methodology for the last thirty or forty years has been aimed at creating processes by which mediocre programmers can produce reasonable quality code in a reasonable time. Unfortunately nothing will ever change the fact that the productivity range of programmers spans an order of magnitude, possibly two depending on who you listen to.

Want good quality results? Hire 5 good programmers, not 15 mediocre programmers. That means that you'll probably have to pay them pretty good coin and treat them well and that is management's real problem. Management dreams of cheap replaceable labor working on an assembly line. After all assembling cars and developing highly sophisticated software have so much in common!

As for the comments on disturbing concentration - absolutely! Any significant chunk of code is highly complex and detailed. It needs to be kept in the head as a whole, in an organized fashion and in detail. It is nothing short of mind boggling that anyone can imagine that a process that requires being continually interrupted and distracted will aid that task. This is nothing but another doomed attempt to take the bottom 10% of the talent pool and try and squeeze some productivity out of them.

Range and availability of Skilled People (2, Insightful)

omb (759389) | about 5 years ago | (#27460647)

The skill range is actually infinity, as there are people who just cant program.

Of those that can 100:1 is normal

The US is going to have to grow up, and get educated again, or other places really will eat their lunch. Fortunately Obama seems to realise this, but neither Mainstreet or the rest of the world will put up with the MBA/Wall street culture again.

If you listened to the G20 proceedings you will realise just how surely the game is up

Re:Either trivial or bullshit (2, Interesting)

Gorobei (127755) | about 5 years ago | (#27460615)

Hmm, a lot of different programming models are optimal because there are a lot of different business models.

Independent, decent programmers works great for the "grip it and flip it" model of getting software out the door.

I've got 10 million lines of production code, and I want every single change to make that codebase better, not worse. So, yes, you check in a while loop when it should be a for loop, at least two people are going to tell you to fix it before it's considered for production. I bitch about poor function names, bad idioms, pointless abstractions, code that rolls past 140 columns or so: don't leave crap that slows down the next person.

Oh, and each programmer gets 30 or so square feet of workspace, so they have 30 people within yelling distance if they need help while writing the code. Feels like CS-lab, but with rich programmers :)

Re:Either trivial or bullshit (4, Informative)

julesh (229690) | about 5 years ago | (#27460895)

And for the record: a few years ago there was a study published in Communications of the ACM that showed while pair programming is more efficient than a single solitary programmer, it is not as efficient as two programmers with two keyboards. FYI.

That's one study. I imagine the one you're talking about is "All I really need to know about pair programming I learned in kindergarten" by Williams and Kessler. This study has been criticised for its focus on performance over and above accuracy. I'd suggest you look at some of the broader studies that have been published since that one, e.g. Williams, L. Kessler, R.R. Cunningham, W. Jeffries, R. "Strenghtening the case for pair programming" (IEEE Software), finding that a 50% speedup over a single programmer, which is in the same order as two programmers working independently, but more importantly a 13-17% reduction in the number of bugs discovered after signoff, whereas you would usually expect an increase with two programmers working independently. Nosek 1998 (also a Communications paper) found a 41% speedup, which is less than you would expect from two programmers individually, but also found a 43% increase in evaluations of code readability and a 33% increase in evaluations of resulting functionality of the software developed.

So, yeah, basically the point is that while two people at separate keyboards may produce a larger volume of code, the code produced during pairing is more likely to solve the problem that it was actually required for, and will be more maintainable afterwards. And we haven't even touched on the fact that pair programming spreads knowledge of the design of the codebase the team is working on, thus helping the team maintain the software at a later date, or that most programmers find they can keep up pairing for longer periods of time than they can code by themselves, or that job satisfaction is generally higher for programmers who pair.

And your description of how you think when you code betrays that you have dismissed this without trying it. You think differently when you're pairing. It's just as effective (if not more so), and the interruption is not a problem.

Re:Either trivial or bullshit (2, Insightful)

mdwh2 (535323) | about 5 years ago | (#27460309)

They think their job is to produce code and avoid communicating with others as much as possible. Witness the common reaction to the idea of pair programming

I think this is one extreme to the other - I think pair programming is bad for many reasons, but that doesn't mean I can't communicate. It's important to be able to write documents, communicate with other developers, managers, customers, and so on. But that doesn't mean I want to have to be conversing 40 hours a week for everything I do.

I might as well turn it the other way round and say that someone who thinks that communication is important is incapable of working on their own. Obviously, that would be unfair too - it's most effective to balance these things, rather than being at one extreme.

Re:Either trivial or bullshit (2, Interesting)

murdocj (543661) | about 5 years ago | (#27460377)

Witness the common reaction to the idea of pair programming: "it'll disturb my concentration... it's hard to hold the details of your coding in your head if you're talking to someone". Well, frankly, you need to be able to communicate those details, so you _should_ be able to talk to somebody about the coding while you're doing it.

I'm often complimented on my ability to communicate ideas and document clearly. I also hate pair programming, pretty much for the reason listed above. The way I like to work is to cycle between talking to one or two people hashing out the ideas, and designing / coding. But when I'm trying to read code in detail, or lay out the details of code, the last thing I need is someone interrupting me every time I'm about to do something. That just doesn't work for me. I have sat with people to pair on particular problems, and that works fine, but it comes in the natural flow, when we're both ready to do it. The "continuous pair programming" approach, as far as I can tell, has way more to do with power and control than it has to do with communication.

Re:Either trivial or bullshit (1)

AuMatar (183847) | about 5 years ago | (#27460987)

It's really about fixing flaws in the rest of XP. In XP, you're supposed to skip desig an div straight into coding. So when you code, you're doing design and implementation at the same time. Given that, it makes a lot more sense- using another programmer as a sounding board in design can be very helpful. So pair programming is necessitated by the lack of design- if there's an obvious design flaw its more likely to be caught. Of course, the real problem is you completely skipped an important stage of development and it would be both easier and more efficient to catch it then. But that's the problem with Agile- rather than try to figure out the right amount of time to spend on preparation, they threw the baby out with the bathwater.

Re:Either trivial or bullshit (1, Interesting)

Anonymous Coward | about 5 years ago | (#27460555)

Witness the common reaction to the idea of pair programming: "it'll disturb my concentration... it's hard to hold the details of your coding in your head if you're talking to someone".

You're grouping all "coding" together. For experimental coding, pair programming might make very little sense, for example. Just because it involves typing that produces source code doesn't mean it's all the same.

Well, frankly, you need to be able to communicate those details, so you _should_ be able to talk to somebody about the coding while you're doing it.

This seems misguided. Programming *is* communication. As SICP put it, "programs must be written for people to read, and only incidentally for machines to execute". Spoken word and source code each have their strengths. I can't ask a question of some source code, but I also can't grep that conversation we had 2 months ago.

A good programmer should be able to communicate well with either medium. If you can't communicate in code (one-to-many persistent communication), communicating in speech (one-to-one volatile communication) won't help much.

The focus is on the implementation, not the communication. It should be the other way around.

Again, shoehorning. With experimental programming, the programming is not about implementation, but about generating ideas. But even if you're doing boring work, why do you need 2 people programming? Work out the ideas together first, and then the implementation is easy for one person to do.

Looking at all the great programs and terrible (or aborted) programs, I see pair programming as an averager. Neither the great programs nor the horrible ones were pair-programmed. Pair programming seems like a hedge: you probably won't fail, but you probably won't make something great, either.

To me, the conclusion is clear: people will try to use PP at companies when they're uncertain of their teams. And they'll produce average programs, and which will get beaten in the long run by some person in a garage with a cheapo PC, who can produce a new innovation, not just a competent implementation.

Computer programming is a really new field, and yet, it's not taking any lessons from mature fields. When two authors write one book, you don't see them sitting down at a keyboard together. Nor two composers, or any other pairs. But more generally, most good creative (as in, the act of creating anything new, not necessarily 'artsy') work is done by *one* person. The problem with programming isn't that people need supervision; it's that our tools are still so low-level that one person can't reasonably design-and-write a whole program. You just don't see users passionate for programs today like you did in 1986, when they were written by one guy.

Re:Either trivial or bullshit (1)

Daniel Dvorkin (106857) | about 5 years ago | (#27461311)

Well, frankly, you need to be able to communicate those details,

Yes.

so you _should_ be able to talk to somebody about the coding while you're doing it.

No.

Talking about your code while you're writing it is not the same thing as writing effective documentation, or even explaining the code verbally, after the fact. The latter is vital to to any non-trivial programming project; the former may be an effective technique on occasion, but most of the time it's utterly destructive to good programming. The best code is written by one programmer staring at the screen and thinking really hard -- specifically, thinking a lot more than typing or talking.

Re:Either trivial or bullshit (0)

Anonymous Coward | about 5 years ago | (#27460807)

3. "He says that the U.S. economy in the future won't need any people with technical skills, only managers, as technical skills can be outsourced. This is bullshit, as the U.S. is going to experience the hard way in the upcoming years.

"

The magic words are (American), "economy" & "need." Today, we measure the 'economy' soullessly in terms of $'s. The Dismal Science has never made room for anything but that which can be measured in terms of currency. Therefore, my value is commensurate with my salary, and anything else is irrelevant to an economist. Ergo, it does not matter what the U.S. 'experiences' in human terms. All that matters (to the dismal economist) is whether the GDP (no longer the GNP) is growing. Even when growth is measure in terms of inflated dollars and wages are falling in 'real' terms, this is true (to an economist). Change the premise and you change the equation.

The message from World's Fair from the 1930's, constructed by it's most influential architects, Dow Chemical, GE, GM, Westinghouse, and the like, was that technology was good for you and me, not just the executives, the stockholders and the board of directors. The swindle was propa(nda)gated using the rhetoric of the economist. We were all told to accept that an increase in productivity (that which justifies the investment in technology) would lead to a better standard of living, a 4-day work week and more of everything, for all. Has it happened, no. Is it likely to happen in a world with unlimited cheap labor, no. Do you have to accept that, no. Do you have to live with it, yes. Because, unless you are willing to cease your participation, along with everyone else who is competing for the brass ring, the highest bidder owns your sorry ass. (Ha-ha. For every one of you complaining about the requirements of toil in your high paying techno-weenie, button-pushing, barrel hugging positions, there are 2 others who are ready, willing and able to take your place and more than enough H1-B Visas to go around).

It's called, "competition," and the finish line is just around the next bend, through Bretton Woods, and over the next barrel. But don't worry, God is on your side, we are all in it together, and your government (chosen democratically by those who are 'informed' by Disney [ABC], GE [NBC] and some other multi-national conglomerate [CBS]) is here to help you because We The People are the ultimate source of power.

Revolution ( )

IF {you don't like the status quo}

THEN {Shut up and start coding something useful}.

Engineers should run tech companies not MBAs (5, Insightful)

TheNarrator (200498) | about 5 years ago | (#27459669)

I think the anti-pattern I see in most companies that are weak in the technology area is the guy at the top is great at landing deals, public speaking, and sales but he can't figure out what those damned pesky nerds are doing and why they need to get paid so much money.

As a general rule, most successful tech companies are started and run by people with engineering and/or cs backgrounds (Google, Paypal, Ebay, Microsoft to name a few). Many companies these days, which are in the information handling business (finance, etc), have little competitive advantage over their competition except for their technology platform and are thus essentially tech companies, even though they might not know it yet. Now with the down economy they actually have to be better than the competition and can't just survive by endlessly rolling over credit lines. Hence, the greater need for engineers who can create a technological vision for the company instead of just doing what they are told to do by clueless bosses.

Re:Engineers should run tech companies not MBAs (1, Interesting)

phantomfive (622387) | about 5 years ago | (#27459925)

The problem is, eventually all technology becomes a commodity. Open Source is a big driver on this. For an example, take word processing: there are tons of good word processors, some are better and some were better than Microsoft Word. A word processor isn't even worth money, you can get it free. Yet why is Microsoft Word the defacto standard? Because Microsoft has the sharpest business skills. Microsoft isn't at the top of the heap because they know technology, it's because they have good business people. That is their competitive advantage.

For the general public, it is better if technology becomes a commodity, because then the only way the players can compete is based on price. If you are trying to make a profit, it sucks. This is what Apple is doing: they don't want to compete head to head with the PC world, they want to avoid becoming a commodity and avoid having to sell their stuff for as cheap as possible. The MBAs usually know tricks to manage this. Tech people usually don't. Thus tech only companies tend to go out of business after a while, and the ones that stay around have been taken over by MBAs.

Re:Engineers should run tech companies not MBAs (0)

Anonymous Coward | about 5 years ago | (#27460677)

See: Sun Microsystems, DEC, etc.

One size doesn't fit all (5, Insightful)

blueforce (192332) | about 5 years ago | (#27459671)

I'm always amused when I read stories like this about how X or Y is the only possible future of development.

What works for one application or company doesn't necessarily work for the next. This isn't a one-size-fits-all industry. If it were every company would be using the same languages with the same methodologies.

Meh.

Partially right (5, Insightful)

TrailerTrash (91309) | about 5 years ago | (#27459689)

Leaving development decisions to core programmers can lead to chaos in development priorities. A hard core coder may spend large amounts of time chasing down just that little bit of latency in the process scheduler; but what the business needs is a rewrite in order to simplify processes.

This is why the OS model has a hard time living in the corporate environment. Many times what needs to be done for the business is tedious programming driven by idiots (== users). No one wants to do that. So a core group of programmers ends up adding a plethora of new features that are elegant in implementation, advanced in design, and useless for users.

The other major factor in corporate America (can't speak for the other 96% of the world) is the vast armies of "business analysts". These people allegedly have communication skills with both users and coders. In reality, however, they are incented to drag out projects in requirements and testing phases in order to make their own functions seem more useful. Many projects I've worked on have burned upwards of 3/4 of the hours billed to business analysts.

The remedy? Coders who can speak Business, are WILLING to speak Business, are willing to let the needs of the users drive their projects, and the ability to code. In that order. These people are far and few between, sadly.

In defense of business analysts... (4, Insightful)

Stiletto (12066) | about 5 years ago | (#27459759)

I've seen my share of products fail miserably because nobody brought in the business analysts or consultants to gather functional and end-user requirements and spec out the system, and, generally, drive the project. Consequently, the engineers are left with an incomplete or incorrect idea of what to build or of what the acceptance criteria should actually be.

Re:In defense of business analysts... (1)

Burnhard (1031106) | about 5 years ago | (#27460639)

I've seen my share of products fail miserably because nobody brought in the business analysts or consultants to gather functional and end-user requirements and spec out the system, and, generally, drive the project. Consequently, the engineers are left with an incomplete or incorrect idea of what to build or of what the acceptance criteria should actually be.

Well that's where communication comes in. It's easier in small teams, where the people in contact with the customers are easy to reach when a subtle choice-point comes up during development. Larger companies tend to be more beaureacratic in this respect, with a greater distance between those making the decisions and the actual developers. When this happens the way the developer visualises the software is critical. If you're parcelling up development into little pieces and giving it to people to code up, those people have no concept of the whole and therefore are incapable of making intelligence choices about how best to proceed.

In my view and from my experience, it's critical that each developer can see the whole project and his part in it. It's why many seemingly simple software projects, when out-sourced, end up costing millions of dollars over budget and are often delivered late.

Re:Partially right (0)

Anonymous Coward | about 5 years ago | (#27460913)

At the other end of the scale, I've worked on projects that failed because us coders were the only people with a clue. Analogy time...

Don't bother with the foundations, the end user just wants a roof over their head. Start with the roof and then we can go back and complete the rest later.

Sounds stupid and yet this is the kind of bullshit software development teams have to put up with. Then there's the vendor-whore and the buzzword-victim/fanboi; insisting you use the wrong tool for the job.

Hey, I know you guys want to use a mechanical digger but I've got a great deal on plastic trowels. Buckets! Plastic buckets are the hotness, I read an article on buckets recently and I just happen to have some in my garage. We also need to bring the next milestone forward.

Re:Partially right (0)

Anonymous Coward | about 5 years ago | (#27460937)

This is why the OS model has a hard time living in the corporate environment. Many times what needs to be done for the business is tedious programming driven by idiots (== users). No one wants to do that. So a core group of programmers ends up adding a plethora of new features that are elegant in implementation, advanced in design, and useless for users.

You've just described one of the biggest "problems" with desktop linux. Nobody wants to write code for idiots or work on boring projects; they would rather spend their time making mplayer play video in ASCII art.

News? (4, Interesting)

drolli (522659) | about 5 years ago | (#27459701)

Coding skills are still a necessity. However they never have been sufficient (as the Example of the Reiser vs. Kernel developers shows). If you look in many completely failed projects of the past, and you read the story carefully, a lack of communcation is a very likely reason for *big* trouble (Read the Commodore story....).

This is actually more about innovation management (3, Interesting)

anomalous cohort (704239) | about 5 years ago | (#27459711)

There is a lot to be said for the bazaar model of intellectual work. The open source model is certainly an early adopter but by no means does it have a lock on this approach.

There is a whole new crop of innovation management tools [blogspot.com] that use crowd-sourcing techniques as a better way to work.

May I humbly submit some of my own tools in this field as examples here? Take a look at this general purpose problem solving platform called Cogenuity [dynamicalsoftware.com]? Cogenuity currently uses a challenge based approach with a heavy emphasis on social networking and collaboration.

Another tool that I wrote is Code Roller [code-roller.com] which is a collaborative software development project life cycle management solution. It combines software engineering deliverables, process and workflow with project management practices, social networking features, and a crowd-sourcing style recommendation engine.

Both of these tools are free as in beer.

Oh, by the way, the infoworld link from the original submission here is broken.

Blame open source (4, Interesting)

clarkkent09 (1104833) | about 5 years ago | (#27459723)

The problem wouldn't have arisen in the first place if the programmers have not as a rule undersold their skills (not least by happily working for free) to the point where they are treated like shit and paid accordingly. The way to do it is to emulate lawyers (as a rule less intelligent than programmers, but not when it comes to money) and sell themselves as highly skilled practitioners of a mystical craft that can only be performed in high priced suits with gold rolexes and not for less than 300K/year

Re:Blame open source (4, Insightful)

Stiletto (12066) | about 5 years ago | (#27459829)

Lawyers can charge what they do and sell themselves as highly skilled practitioners because they passed the Bar exam, which acts as both a hurdle to keep everyone and their uncle out, and as an indicator of some standard level of performance.

"Coders" have no such yard stick. Anyone and their uncle can call themselves "coders" or, even more outrageously, call themselves software engineers. There's really no certification, standardized exam, or prestigious private college out there whereby one can stand out as highly skilled. So, the field is flooded with tons of mediocre and unskilled coders, punctuated by the rare skilled programmer. This drives salaries down. Everyone in the field is forced to undersell themselves lest they be underbid by one of the many who are all talk and no skill.

What software engineers need are credible and selective certification programs so that the few very talented professionals who pass can authoritatively show themselves to be skilled. This would definitely help weed the field of posers and amateurs and bring salaries up to where they should be.

Re:Blame open source (1, Insightful)

Dragonslicer (991472) | about 5 years ago | (#27459895)

"Coders" have no such yard stick. Anyone and their uncle can call themselves "coders" or, even more outrageously, call themselves software engineers. There's really no certification, standardized exam, or prestigious private college out there whereby one can stand out as highly skilled.

You mean my MCSE doesn't make me a skilled software engineer?

Re:Blame open source (4, Interesting)

mysidia (191772) | about 5 years ago | (#27459927)

A MCSE does not certify a software developer. It's an entry-level certification for Windows technician skills.

MCSD comes a little closer -- it certifies the ability to utilize certain development tools; however, it doesn't really certify engineering skills.

The best certification I know of for software development skills is to have been the main contibutor and maintainer for a successful open source project for 12 months. Where 'main' contributor is defined as having written at least 30% of the code.

And 'successful' means you have a (PROGRAMNAME)-users mailing list or forum with at least 100 active subscribers, who have all downloaded the product, and you can measure your number of downloads of any new version of the software in the hundreds of thousands.

Re:Blame open source (3, Insightful)

Microlith (54737) | about 5 years ago | (#27460045)

And 'successful' means you have a (PROGRAMNAME)-users mailing list or forum with at least 100 active subscribers, who have all downloaded the product, and you can measure your number of downloads of any new version of the software in the hundreds of thousands.

Wow, that's an incredibly arrogant and impossibly high bar to meet. I guess you want to limit the number of "certified" software developers to what, 300? And do what with the rest, fire them all?

Re:Blame open source (2, Interesting)

mysidia (191772) | about 5 years ago | (#27460611)

No, they can still be software engineers. Just not with that particular certification. In computer-related fields, people have a lot of flexibility and no one-cert is the be-all end-all that everyone has to have.

Just like you can still be a computer security professional, even if you don't have a CISSP cert.

You can still manage networks without a cisco cert.

You can still admin Redhat systems, even if you don't have a RHCE, or Apple systems without a ACSP.

You can be elected city mayor without passing a "Mayor Certification" test

You can work as a java developer without a SCEA.

On the other hand... certs whose major component isn't just passing a test, but also require real-world-like things to finalize or complete the cert (such as doing a project that was actually successful) ought to mean much more than Sun certifying you as a Java programmer or Java architect on the basis of passing a multiple choice quiz.

Not to mention the possibility of cheaters on multiple-choice tests, or people who just memorize lists of all the possible questions (they got online from other test takers).. Which severely dilutes the value of all multi-question-test certs.

A lot of uncertified people are really qualified, and avoided certs due to the high cost, in terms of fees.

For one cert to ever become de-facto standard, there would have to be agreement in the industry which doesn't exist, or it would have to be totally vendor-blind which limits its value.

You can't certify C++, C#, or Java developers with the same test, and ask specific questions, unless it either doesn't mention any language-specific features: or it provides questions with the code sample in all 3 languages, where the answer is the same for all 3.

Because there are so many certs in every computing field, the value of any individual cert (or list of certs) is highly diluted.

You put SCEA on your resume... the hiring manager may see your line that says "SCEA" and may very well think "What the hell is a SCEA?"

You practically need a certification to indicate that you KNOW what the names are of all the computing and developer industry certs out there.

Re:Blame open source (1)

roguetrick (1147853) | about 5 years ago | (#27459931)

I'm too tired to go into a real sociological discussion about this, but those sorts of things tend to bring wages up but also ensures it costs more to enter into the profession and weeds out talented individuals who just don't have the capital.

Re:Blame open source (3, Interesting)

Rakishi (759894) | about 5 years ago | (#27460955)

Lawyers don't get paid a lot, some lawyers get paid a lot. Just passing the bar exam gives you more or less nothing.

You have to go to a good school, rank highly at that school, do well on the bar exam, join a well known law firm, work your backside off for 80 hours a week and so on.

Re:Blame open source (1)

Simon (S2) (600188) | about 5 years ago | (#27459835)

not for less than 300K/year

Your ideas are intriguing to me and I wish to subscribe to your newsletter

Turf battle (2, Funny)

oldhack (1037484) | about 5 years ago | (#27459751)

Guess this is meant for CEOs and CIOs. Interesting ammunition for office politics, but it's CYA time these days - not the best timing.

This has been happening since the late-1980's (4, Interesting)

mikael (484) | about 5 years ago | (#27459757)

Even back in the late 1980's it was obvious that thin pyramid management structures were being toppled through downsizing. Some of my relatives took early retirement from companies due to this. Long chains of management over 15 levels deep were definitely going out of fashion: director, assistant director, senior manager, assistant senior manager, supervising manager, project manager, assistant project manager, team leader, lead programmer, senior programmer, programmer, junior programmer and intern.

Start up companies just a far simpler structure: director, software/hardware architect, team leader, senior programmer and programmer.

Everyone knew about the hazards of "dead man's shoes" and how important it was to keep your skills up to date or lose your career.

Re:This has been happening since the late-1980's (1)

EsbenMoseHansen (731150) | about 5 years ago | (#27460035)

Start up companies just a far simpler structure: director, software/hardware architect, team leader, senior programmer and programmer.

Everyone knew about the hazards of "dead man's shoes" and how important it was to keep your skills up to date or lose your career.

That is far too many levels. Cut out the software/hardware architect, they are pretty useless with a skilled force anyway. Then have a group that includes strong people skills, strong architectural skills, good system programming, good organization skills and make sure everyone except perhaps one or two is a strong programmer. Then have everyone code (perhaps only a few hours each week for 1-2 people), everyone help out with customer interaction and Bob's your uncle ;) Of course, budget and such needs to be worked out at least to some degree beforehand, and perhaps someone external should be able to pull the plug.

Of course, that does require a team of independent, passionate and good people. But seriously, I don't think it pays to have any other kind on your team.

Disclaimer: This home-brewn claims to be 5.5% alcohol, but I get the feeling that I measured it wrongly, so what I write might make no sense ;)

Where are they going to find these managers? (4, Interesting)

weston (16146) | about 5 years ago | (#27459779)

And this shift will require managers to look beyond résumés 'choked with acronyms and lists of technologies' to find those who 'can understand, influence, and guide development efforts, rather than simply taking dictation.'

I think an equal question is where they're going to find more managers who aren't the habit of seeing coders as black boxes into which their decisions go in and desired code comes out.

People like to talk about the archetype of the "techie" who is, of course, good with technology but doesn't understand much else. I suppose I've met people who embody this, but generally, my experience is a little different: I frequently meet programmers who are three dimensional people who may be good at writing, music, presentation... even sales. So I wonder sometimes where this persistent stereotype of the "techie" comes from.

Mind you, this happens the other direction as well: I see programmers who are convinced the "soft skills" of other professionals are easy to pick up and practice and they could be doing any job in the company.

Re:Where are they going to find these managers? (4, Interesting)

David Gerard (12369) | about 5 years ago | (#27459909)

Yeah, people like that [today.com] are why female geeks leave the industry. Developers who think they're brilliant communicators until they actually have to talk to a human.

...

The number of female IT professionals in the UK is falling, according to the British Computer Society, despite similar or superior academic scores and recruitment in the sector as a whole having risen in the same timeframe. The lack of flexibility offered by employers is blamed.

"It's a free market world," said Ubuntu Linux developer Hiram Nerdboy. "It's about competence and getting the job done. Working sixteen hours a day on a project you really love is par for the course. That we're all eighteen to twenty-five is from the accelerated Internet-based learning of the new generation, not exploitation of young workers who donâ(TM)t know any better."

Over a third of women in IT had complained of sexism up to sexual harassment at work. "Itâ(TM)s women who just don't have social skills," said Nerdboy. "They object to the guys freely choosing to all go down the strip club after work. Theyâ(TM)re just not team players."

Open source projects have worse figures than industry, with male to female ratios approaching fifty-to-one. Many women cite gross sexism on mailing lists and IRC. "In my experience, women just don't have a working sense of humour and canâ(TM)t take a joke. My girlfriend thought it was funny! Even leaving helpful comments on their blogs didnâ(TM)t work. 'Political correctness' is no exaggeration. Anyway, I met my girlfriend online!"

"...," said his girlfriend, RealDoll Ada.

"And it's not like you can get the applicants," added Nerdboy. "We can hardly get any girls to apply for a job here. They're obviously naturally not good enough geeks. It must be evolutionary. We need more pink computers."

Re:Where are they going to find these managers? (1)

Ironpoint (463916) | about 5 years ago | (#27459979)

So I wonder sometimes where this persistent stereotype of the "techie" comes from.

Labor competition. When a tech worker or manager feels threatened and wants to belittle a coworker's skills they start on about the coworker's 'communications skills' and so forth. In reality they are trying to paint themselves in a relatively brighter light, but are going about it in a wrong way.

Re:Where are they going to find these managers? (2, Insightful)

Anne Thwacks (531696) | about 5 years ago | (#27460563)

I wonder sometimes where this persistent stereotype of the "techie" comes from.

Dont you watch the mass media? The media are run by people who failed basic science, and assume that, because they are clueless about sci/tech, that anyone with sci/tech understanding must be as clueless about the rest of the world as they are about sci/tech.

Not only that, they often have a huge personal comittment to protraying techies as "wierd" because it justifies their own willful ignorance.

Bear economy (1)

Dosha (1403403) | about 5 years ago | (#27459803)

<i>communication skills, not coding skills, are a developer's greatest asset in a bear economy</i>

Actually, the greatest asset is the ability to claw trees to mark your territory and attract mates.

This confirms my theory of human behavior (1)

Pictish Prince (988570) | about 5 years ago | (#27459831)

There are 4 basic types of people in the world: Bean-counters, arm-wavers, geeks and outlaws. This piece was obviously written by an arm-waver.

Yeah, right (3, Insightful)

thethibs (882667) | about 5 years ago | (#27459849)

Switch to the open source model of development where the only things that get implemented are the things the developers are interested in. With all due respect, this would be a return to the bad old days of mainframes when users had to put up with whatever the data processing department built and be happy that they had any automation at all.

One of the dumbest ideas I've seen on my screen in one devil of a long time.

Re:Yeah, right (0)

Anonymous Coward | about 5 years ago | (#27461129)

What? Being at the mercy of one author or vendor is the the big problem with the closed-source model. Open source means you can pay or persuade anyone competent and get any changes you want, because nobody is exercising any authority to tell you no.

I'm set.... (4, Funny)

feepness (543479) | about 5 years ago | (#27459975)

Well-well look. I already told you: I deal with the god damn customers so the engineers don't have to. I have people skills; I am good at dealing with people. Can't you understand that? What the hell is wrong with you people?

Coders vs Business Analysts (1)

Baron_Yam (643147) | about 5 years ago | (#27460009)

I'm nominally a coder. I know the application I'm extending VERY well, but I have only the vaguest idea what the users require. This leads to me working on areas where the application is inefficient, but often working on an item that should be at the bottom of the priority list.

The solution is good communication with the users (I try) and explaining to management what I think needs to be done and why.

I can't imagine that people who are experts in business needs, work flow, and applications all at the same time are common, especially as you get into larger projects. There is a reason these jobs are seperate.

Can't emulate open source (2)

syousef (465911) | about 5 years ago | (#27460031)

Instead, companies should emulate the open source model of development

1. Your mother's basement isn't large enough for the whole company
2. There may be liability issues if you put your company on a diet of pizza and coke
3. Employees want to be paid.
4. It's hard to ship product when all you do is squabble and pull the project in different directions
5. Most of your employees will prefer to shower.

If you mod this as troll you have no sense of humour whatsoever

Kick the people who do the actual work. (1)

WoollyMittens (1065278) | about 5 years ago | (#27460081)

If managers are to be the nation's greatest asset, then we're all doomed. There will be nobody left without any technical skills. Sure you can outsource that work, but this causes a disastrous increase in the already epic trade deficit and the Asians are already finding out that they don't actually need the fat manager cats abroad at all. Only engineers and artists can create things of value. There rest, especially management, exists only to support the people that actually know how to make something.

The problem is the meritocracy (2, Interesting)

FATRanger (516532) | about 5 years ago | (#27460087)

The author states that code improvements should be driven by "the developers with the deepest architectural understanding of the code, the closest interaction with the code, and the most responsibility for the code". However, this is a programmer biased perspective and not at all how a business operates.

A business is focused on making money. For the founders, the owners, the stakeholders with the most financial resources invested, that is what it comes down to. That is why if they find an employee that can generate more of it form them they are more likely to listen and give "the greatest decision-making power" to. Normally this ends up being the sales person, marketer, etc. They become the CEO. Those that are good at making things work become the COO.

While things are going well and the company is successful people will not question this model. Customers will request features, companies will implement them. When resources are short they will hire more people, layers of management gets added, everyone feels like their job is/can go somewhere.

The problem occurs when those in charge become lazy or egotistic. The lazy manager will stop gathering user input, or fail to understand why developers gawk at the 100th feature request that are not followed-up on for the month. The impact on morale is the real cancer that kills ideas and companies.

The egotistic manager will achieve similar results, but for different motivations. The incessant push for their ideas, the attempt at pressuring coders to succeed for them, etc. is too shallow and most egotistic managers are not good enough leaders/manipulators to actually motivate people even if it were for purely selfish purposes.

For a coder the best skill is not communication skills, although it is important, but business skills. If you can make money, you can do whatever you want. If you are good enough you can leave all the petty office politics behind and start your own enterprise.

Following another manager, however great, will never lead to security for the pure developer. This is because in the scheme of things you are just carrying out the vision of someone who helps the company achieve financial success. Just as soldiers are trained not to think too much, that is what managers want out of their coders as well when they have an agenda.

The times where I have seen managers ask developers for ideas and comments are when managers are out of ideas. In which case they do so less out of a willingness to communicate and more out of desperation. That is why many CEOs describe their job as cultivating a culture because in a "my way or the highway" environment there is no way people will bother suggesting alternatives.

If a coder wants security they need to first prove their worthiness to decision makers that they can be one of them, then lead and succeed for the organization; basically become a manager themselves. All of this requires a lot of investment in time and effort away from the text editor/IDE and a lot more time in front of people.

This is why there will always be a divide between managers and coders, the roles simply require different skill sets and to be good at either is not easy. The best of either class are good at reaching out, which still requires both parties to be willing to participate for the exchange to occur.

Well, yes. And? (2, Interesting)

prefec2 (875483) | about 5 years ago | (#27460135)

I have worked with people who can be categorized as coders. Some of them are good in writing down code blocks some of them are not so good at it. However, most of them arm poor in communicating, contributing in the design phase, or shutting up and implementing the stuff they're asked to do.

The problem is, that they like to code, but not to plan. But without proper planning no project ever gets finished. So the first problem is that they do not really contribute to the high-level design (if they are invited) then they are not very communicative when they are asked to contribute to the detailed design. Mostly for strange reasons:
a) The high-level design is flawed in their eyes, but they never bothered to tell anybody when they were asked.
b) The don't like one or two technical decisions. This demotivates them.
When you reach implementation phase, they hate to read documentation of the design or underlying frameworks, which results in duplication of framework functions. They work that way because they like to code, but hate to read specs., framework documentation, or the design. Sometimes they deviate from the design, just because they think their idea is better than the concept in the design.

So it is difficult to catch them before they go crazy and you have to look after them often. At least until they know the routine. And the frameworks used.

It is easier to work with people with more CS knowledge, because they understand the necessary of proper planning and design. They are able to discuss design issues and most of them speak their mind. Also they are able to have a discussion and accept better arguments from their colleges. Also most of them are able to learn a new language more quickly.

Well what I wrote above is very black and white, but sometimes you have to exaggerate to make a point.
   

Pointless? (1)

readin (838620) | about 5 years ago | (#27460259)

Will working Saturdays save me, or should I take the rest of the day off and enjoy the weather?

We still have coders? (1)

buss_error (142273) | about 5 years ago | (#27460317)

Hey, fifteen years ago it was supposed to be in five years computers wouldn't need code monkeys because they'd program themselves. Ten years ago it was Nural networks that were going to put coders out of work. Five years ago it was "eveyone will know how to code". Now it's elbonia putting us out of work. You ever work with an elbonian coder? Ever notice how everything you ask them to do comes out slightly (or not so slightly) wrong?

Not that I care - I quit coding for a living years ago. Now I hold hands for a living. (Well, that's when it *seems* like - the life of a sys admin....)

Show me an example (no, a good example) (1)

Thad Zurich (1376269) | about 5 years ago | (#27460337)

If Limewire 5 is an example of "the open source model of development, shifting decision-making power to the few developers with the deepest architectural understanding of, and closest interaction with, the code", then they can shovel it.

Our days are numbered. (2, Funny)

Ironchew (1069966) | about 5 years ago | (#27460343)

For example, today is 04/04/2009. It's a very useful technique, maybe Slashdot just wanted to let us the power at our fingertips?

Re:Our days are numbered. (0)

Anonymous Coward | about 5 years ago | (#27460373)

I'm not a number, I'm a free Saturday!

Re:Our days are numbered. (1)

Anne Thwacks (531696) | about 5 years ago | (#27460599)

today is 04/04/2009.

Or, in most of the world, 2009/04/04.

To be sure its a great idea that America needs more Chiefs and fewer Indians. Isn't the real problem: too many cowboys!

Overseas (0)

Anonymous Coward | about 5 years ago | (#27460367)

There you have your biggest problem. Sending your work overseas will just set you up for an epic fail.

Damn (0)

Anonymous Coward | about 5 years ago | (#27460369)

First thing I've thought when I saw the title was "Holy shit they have superior AI running on superior computer that can code". Damn

Re:Damn (0)

Anonymous Coward | about 5 years ago | (#27460515)

they have inferior brown skins who work for cheap.

CMS Systems (1)

mmsimanga (775213) | about 5 years ago | (#27460523)

I am doing a study trying to find the most cost effective method to develop small in house systems. I am leaning towards using an Open Source Software (OSS) Content Management System (CMS) type of architecture. Here is why:

By nature OSS is modular; the core system is supplemented by third party modules. Through OSS methodology iterative refinements these modules soon become pretty nifty and are able to fill most usersâ(TM) requirements. Letâ(TM)s take Drupal for instance and some of the key modules:

CCK - allows user to define different types of content. This is done through a user interface and content fields range from numbers to complex data matrix fields. There are also field to reference users and other nodes hence the ability to create relationships between content and users.

Views - allows you to create views of the current content created using CCK. A view is a selection of the fields you would like to display. Filters can be applied on the fields and dynamic filters such as "Logged in user" are available.

Panels - allow you to create custom content displays. This is similar to web applications that allow you to place different widgets in different locations. In this case the widgets can be views or content or other types of content.

Workflow and Actions - allows you to define a workflow for each content type. Action is the action to be executed when an item reaches a workflow stage.

So for example an application to store a list of employees will typically be structured thus:
  CCK - Employee
  Fields - Name->Text, DOB->Date, Manager->User Reference, Address->Address Field...
  Workflow - Start->
  Views - Employees by Manager, Employees I manage ....

For a task list the structure will be thus:
  CCK - Task
  Fields - Requested By -> User Reference, Date Requested -> Date, Assigned -> User Reference
  Workflow - Assigned, UAT, Complete

I would go on but I think Slashdotters are bright enough to catch to work out the rest

Worthy modules bubble to the top and talented developers chip in and enhance these modules. The users provide testing.

Off course there will always be situations when you will need to write some code but it should not be for every web system if using Drupal. Besides custom code requires too much maintenance.

http://mahalasoft.co.za/ [mahalasoft.co.za] for a survey on Drupal

English influence goes beyond hackers (1)

pingveno (708857) | about 5 years ago | (#27460651)

I sometimes do a bit of gaming with a group of Thai students at my university. Thai is, of course, the dominate language, though they switch randomly between Thai and English. One amusing thing that I've noticed is how strongly English has influenced gamer culture in other languages. There's just something funny about hearing a stream of incomprehensible Thai with the occasional 'noob' or 'rematch!'

Incidentally, I love fish fillets (French), have to fix glitches in my code (Yiddish), use wikis (Hawaiian), love quesadillas with salsa (Spanish), have family in Seattle (name of Native American chief), live near the Willamette River (Chinook), use Ubuntu Linux (Bantu), and regularly drink tea (Chinese).

huh? (1)

Hognoxious (631665) | about 5 years ago | (#27460703)

'The idea that this structure can be sustainable, when the U.S. private sector shed three-quarters of a million jobs in March 2009 alone, is simple foolishness.'

I don't see how the employment figures affect organisational structures and/or development methodologies.

I can see it now (1)

cjjjer (530715) | about 5 years ago | (#27460779)

shifting decision-making power to the few developers with the deepest architectural understanding of, and closest interaction with, the code

The Open Source Model

Client: What are the business rules this action takes?
Developer: RTFM!!!!

Avalanche Process (1)

Hairy1 (180056) | about 5 years ago | (#27461069)

Step aside Waterfall, move over Extreme Programming, there is now a software development process that is popular as it is effective. Yes, Avalanche Development Process will be sure to bring your project to a conclusion quickly and effectively. Read on to learn about this new and upcoming development methodology.

The Avalanche software development process occurs though several stages. In some ways this is similar to Waterfall, but more aggressive. Instead of a calming waterfall we want a Avalanche of productivity. Lets look at how it works.

Project Initiation Phase

In the initiation phase of a project your role as project manager is to secure the largest budget possible. Executive management will however be aiming to reduce your budget to the maximum extent possible, In fact if senior executives had their way you would probably be lucky to get some four by twos to make your own abacus.

It is therefore necessary to be creative in your justifications for the huge budgets you will require. First you must exaggerate almost beyond credibility the benefits to the business of the project. One way to establish the benefit to the business is to perform a Return On Investment Analysis, or ROI. Some project managers spend significant effort doing research and analysis for a ROI. The Avalanche Process has streamlined this process by skipping the analysis and going directly to the conclusion.

You can safely add your unsupported ROI conclusions in the form of an 'executive summary' to random pages from previous projects. No executive ever reads the detail of an ROI primarily because they already know you are a lying weasel. The senior management will then approve your project expecting open ended functionality with half the budget and half the projected schedule described in your project proposal. They do this knowing you have already accounted for this when you wrote the proposal.

Click For More [devcentre.org]

Coders are Manual Laborers (2, Interesting)

Anonymous Coward | about 5 years ago | (#27461089)

Now I don't mean to be incendiary, but I notice a lot of arrogance on the parts of most so-called coders. Disparaging talk of 'manual labors' and exalted speech on the superlative intelligence of coders over other complicated and nuanced professions (i.e. lawyers) seems prevalent in this thread.
But at the end of the day, coders are the manual laborers of the software world, and that is not a bad thing. Anyone who has worked a physical job will be able to immediately tell you the difference between a skilled manual laborer and an idiot who happens to own a hammer. But just as your house, your car, your clothes, your computer hardware, your appliances, and pretty much everything else you use was built by a manual laborer, so also is the software that you use coded by a manual laborer.
The suggested paradigm shift of moving more of the decision making to the programmers makes sense to a degree, so long as those programmers are able to step outside of their insular worlds and be completely cognizant of the role they play.
A construction site has staffed with a strata of management, crew leaders, foremen, etc. Each able to make increasingly more important decisions. A crew leader might be able to tweak the plans a bit to run the conduit here instead of there to make things actually work, but he would not be able to change the placement of the wall. Even if he thought he knew everything about the way the building was to be built, and the engineering of the structure, and the final use. It is not his call. He might be the best damned hammer swinger in the country, but the architect and engineers put the walls where they want them, and it is not his call (no matter how smart he may think he his) to move it.

OK, so this was a long and rambling post, but the final point is that perhaps some of the communication problems that people (read non coders) have with coders is the arrogance and myopic, narcissistic visions they hold.

How to guarantee relevancy: (2, Funny)

shrikel (535309) | about 5 years ago | (#27461135)

So the best way to make sure you'll still be not only hirable, but desirable?

Learn Hindi.

You can't assign creativity ... esp. to developers (2, Insightful)

BemoanAndMoan (1008829) | about 5 years ago | (#27461309)

Programmers are neither abstractly creative nor socially comfortable by default; in my experience it is usually the reverse. To be blunt, they are the worst spellers, often haven't read a book (not text, paper or graphic novel...'book') since high school, and have the communication skills of, well, that chubby guy sitting in the corner staring at the ceiling.

Besides, you only need *one* guy on a team who doesn't sweat like the proverbial whore in church every time he/she has to speak in front of a crowd. Call him king geek, let him speak on behalf the team, and let the rest of the guys get back to work. This is known as "the way it currently works".

Give a programmer a debugger, a pack of Redbull and some clearly defined goals, and he'll work magic. Put him in a suit and tell him to pitch a few new ideas and he'll show up with a cheetos-stained tie and a stress-induced facial tic.

Plato once suggested that we should all be assigned our jobs at birth, and that philosophers should be the leaders. This is sort of like that, but less realistic.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...