Slashdot Mirror
Coders, Your Days Are Numbered
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.
Proponents of Agile development and similar philosophies have been saying exactly this for many years now. Where have you been?
...let the inmates run the asylum. I for one welcome our monkey-poo-flinging overlords!
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.
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.
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.
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.
If you do what you always did, you get what you always got.
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.
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....).
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 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? Cogenuity currently uses a challenge based approach with a heavy emphasis on social networking and collaboration.
Another tool that I wrote is Code Roller 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.
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
Negative moral value of force outweighs the positive value of good intentions.
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.
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
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.
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.
Tweet, tweet.
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.
I'm a Programmer. That's one level above Software Engineer and one level below Engineer.
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?
This same bit of rhetoric happens ever time there is a downturn in the IT economy. It never happens the way it is predicted because coding ends up being harder then the authors think.
As for Agile - another fad, this too shall pass. (We called it prototyping last time around and it failed then too.)
Agile is good a the following:
#1. Product managers and development team leaders can use the make believe "persona" as a way to beat each other over the head with their agenda.
#2. Lets management push developers hard on short term wins that generate enough change to justify a short release schedule and drive up renewal revenue.
What agile seems to be bad for:
#1. Any hope of major architectural change is out the window, along with anything requiring more than a few months to make happen.
#2. QA drops through the floor. Features come fast and furious and compromises have to be made. A strive for mediocrity rules the day.
#3. Documentation ceases to exist in any meaningful sense.
The problem with quotes on the internet, is that nobody bothers to check their veracity. -- Abraham Lincoln