Coders, Your Days Are Numbered 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.
This is extremely old news. (Score:4, Interesting)
How about the model of development (Score:3, Interesting)
Re:This is extremely old news. (Score:5, Interesting)
The subject is being revived by the current economic situation, so not as stale as one might think.
Re:This is extremely old news. (Score:3, Interesting)
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.
News? (Score:5, Interesting)
This is actually more about innovation management (Score:4, Interesting)
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 (Score:5, Interesting)
This has been happening since the late-1980's (Score:5, Interesting)
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.
Where are they going to find these managers? (Score:5, Interesting)
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? (Score:5, Interesting)
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:Engineers should run tech companies not MBAs (Score:2, Interesting)
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:Blame open source (Score:4, Interesting)
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:So it helps to be.. (Score:5, Interesting)
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:This is extremely old news. (Score:4, Interesting)
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 problem is the meritocracy (Score:2, Interesting)
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? (Score:2, Interesting)
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.
Re:Either trivial or bullshit (Score:3, Interesting)
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 (Score:1, Interesting)
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:Blame open source (Score:2, Interesting)
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:Either trivial or bullshit (Score:3, Interesting)
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 (Score:4, Interesting)
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:Blame open source (Score:4, Interesting)
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.
Coders are Manual Laborers (Score:2, Interesting)
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.
Re:This is extremely old news. (Score:4, Interesting)
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.
Re:This is extremely old news. (Score:3, Interesting)
If you can think of something better, let's hear it. I'm not seeing any other methods making people rich just lately.
Re:So it helps to be.. (Score:3, Interesting)
I am involved with hiring and firing where I work. I can tell you, for certain, we have gotten rid of numerous people with good soft skills, whom I personally liked, because I gave them specific technical tasks and they couldn't produce. Sure, the best people have both technical and social skills (and they move up almost too fast!) But given the choice of one over the other, give me somebody who might not sit with me at lunch, but who turns around assignments so quickly it surprises me. You know how it is, one person does in an afternoon what another somehow couldn't manage in 2 weeks.
Re:This is extremely old news. (Score:3, Interesting)
We all drive cars, but using scratch one's itch it implies that we are all mechanics as well. The first drivers of a car where also mechanics though. They had an itch to scratch: how can I drive around town without looking at a horses butt and keeping up the stables etc.
Even up until this day, mechanics and engineers think about what should go in a car. They drive around in a car and say: hey, you know what, it would be really cool if the lights went on automatically after dark because I always forget to turn mine on. Sure many customers might have taught about that but the implementation would most likely be very bad. Why, because they don't think about the way the car works or what can be done with it. They would put it connected to a clock or if they were really smart, put a sensor somewhere on the outside of the car because that's "where it belongs" and putting it inside would be "plain ugly". However they forget that sensors outside a car might get dirty, broken or weatherized really bad. Most consumers however don't see that because they buy a new car every 3 years or whenever something goes wrong with it. Mechanics and engineers however get to deal with 'dumb implementations' or 'customer error' everyday and they see how a car looks on the outside after 12 years, they also know where the least weatherizing goes on and the least stuff gets broken (the dashboard).
Leave the customer to the end-goal. They get to say what they need out of it. The engineers and mechanics get to put it together and though maybe somewhat inconvenient to a customer or end-user, the job gets done well and usually cheap or reusable. I've seen stuff being done top-down and as you pass several layers of bureaucracy and more non-engineers and non-mechanics get to mess with an idea, the worse it gets.
Matrix Layout (Score:3, Interesting)
Does anyone remember Matrix Layout (which later became Objects Layout) from the early 90s? You made flowcharts from ready-made blackboxes. The whole thing was drag and drop. It was pretty impressive during the days of DOS. You had a choice of generating EXEs, or C++, Pascal and BASIC (if you wanted to fine-tune your code). An ad in Byte magazine read: "Not a single damn line of code ever again!" And I had thought back then that the days of mainstream coding would be over by the next decade.
Re:Either trivial or bullshit (Score:2, Interesting)
What few people realize though is that pair programming is boring for the person without the keyboard. It's mind-numbingly boring. It's like watching someone do mathematics homework for a whole day. I enjoy programming, but watching other people code is a lot less fun.
Yes, exactly. Even if somehow pair programming really was more than 100% of an improvement, thus making it worthwhile, from an employee point of view, it would be far less an attractive job. This isn't about being a good or bad programmer, it's just that my preferred job choice was that of "programmer", not "sit and watch someone else code".
Can't Tame the Exam (Score:3, Interesting)
The problem with an "IT BAR exam" equivalent is that software engineering is not yet subject enough to the scientific process to make an objective exam. Can anyone really objectively *prove* that OOP is better than functional or visa versa? That Java is "better than" Lisp? That static typing is better than dynamic? Even objectively proving that goto's are "bad" has been difficult. There's a large psychological aspect to code design.
At best such a test can verify that one is aware of and skilled at different methodologies, paradigms, and languages. But we already have certification programs for specific ones, which is what most HR departments want: a narrow fit.
Plus, the law requires that legal practitioners are licensed before they perform certain activities, such as filing lawsuits. It's not just the knowledge; there's legal restrictions on the unlicensed. I doubt such will exist anytime soon in the software field, except maybe in narrow specialties, such as for medical devices.
Software is weird stuff.
The problem often is on the other end (Score:3, Interesting)
It's often business end people who don't understand the business needs for the code, and don't want to hear it.
Japanese style management is needed (Score:3, Interesting)
Japanese always work in groups. The boss is the coach who negotiates with the team and goes over the business requirements. The team is rewarded or penalized based on results. The coach minimally is but not to the crazy extend as it is in American culture where the CEO gets credit for everything.
Engineers need to make technical decisions and work together in a high performance work group and leaders for different things in the code base will alternate on their own depending on respect and who knows more in each area. The coach just makes sure the business processes are in properly and perhaps gives customer feedback.
Many companies like HP already do this and this is why Japanese cars are so reliable. Engineers make the decisions and not cost saving accountants (with the exception of now Nissan who has American management). If only health insurance companies followed this mantra when accountants make critical medical decisions for the doctors and then the prices skyrocket as a result of mistakes.
Paired programming is annoying but having the geeks hammer it out and do their thing works and the business analysts who has more limited power can make sure it does what it needs to do.
Re:Either trivial or bullshit (Score:3, Interesting)
Am I missing something? Given that most non-trivial companies can parallelise their workload for at least two people, I would expect two independent programmers to be 100% faster than a single programmer.
Most studies have found this not to be true. The extra overhead of communication between the programmers tends to cause an exponential decay in how much additional work is performed by each additional programmer added to the team. Given that most teams are already somewhere approaching the sweet spot on that curve, adding a new programmer doesn't usually result in that programmer achieving more than 50% of what a single programmer achieves. In large teams, it is often found that adding an extra programmer results in no increase in the amount of work performed (see Brooks, The Mythical Man Month). However, adding a new programmer as a pair to an existing programmer doesn't suffer the same problem. The idea enables teams that are twice as large, achieving around 50% more work, before paralysis sets in.
Outsourcing is horribly shortsighted (Score:3, Interesting)
I work for a company which has development groups in lots of countries including India. For reasons that might have sounded great in theory, they farmed off a lot of maintenance development to India - hey it's 1/3rd the price!
As a principal / architect I would often be tasked with overseeing their work, or trying to direct their solutions. That experience was incredibly frustrating for multiple reasons:
a) Cultural differences. Indian developers were the most passive bunch I have ever worked with. They never took the initiative on anything, never offered alternative or better ways to do something, never took time to understand *why* they were asked to do something. Basically if a requirement or design said X they would implement X even if it was ambiguous or nonsensical from a business or coding point of view. Other groups in other countries would push back and the process would improve. This meant the devs had to be closely supervised and all changes reviewed and approved. Tasks took 2-3 times as long to complete which negated any cost savings and also pushed out roll-out times.
b) Language issues. Email was fine. Phone communications were a complete nightmare. Many Indians simply couldn't be understood on the phone. Verbal communication is a critical skill for any programmer. I recognize English is not their first language but its still a requirement and many other countries manage it just fine.
c) Revolving door development. Turnover in India was crippling and every fix or update was handled by different people. This made it impossible to imbue business knowledge, or good coding standards or common practice. Development took longer and the code rapidly becomes a mess of hacks and unsafe techniques.
I'm not saying work can't be farmed out but there has to be a core team of long-term developers. Developers who have business knowledge, developers who will speak out when some requirement is bullshit, developers who have some vested interest in the quality of their code. If you treat developers as an interchangeable commodity you will get back complete shit for your efforts and quality will go down the tubes.
Re:This is extremely old news. (Score:3, Interesting)
Waterfall means think about what you're building, articulate what you're building, then implement what you're building.
Agile means start building something, never think further ahead than what you can code in two weeks, and never articulate what you're building, period.
It's great for disorganized shops producing trivial code for idiots who have no idea what is going on and don't want to. And there are a lot of such idiots with lots of money who want to get a piece of this internet thing but don't like being asked questions and forced to confront their own ignorance.
If you're happy to make lots of money pissing your time away producing irrelevant garbage, Agile can probably help.
Re:Either trivial or bullshit (Score:3, Interesting)
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!
Trying to remain an experienced software developer seems to be like a Sumo wrestling match. You are trying to remain in the center of the ring, constantly gaining skills to feed the family and pay the mortgage. All the time, shareholders (investment companies/bankers) and directors are all trying to reduce costs by trying to turn skills into commodities, and taking on as many staff as possible. Universities are determined to make as much money as possible by churning out as many programmers as possible, all trying to pay off their debts. In between all these forces (Push and Pull from the Peter Principle) are the software developers.