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?
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?
Monstar L
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
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.
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.
Qxe4
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.
No reason to lie.
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.
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.
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.
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.
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 :)
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.
I still have more fans than freaks. WTF is wrong with you people?
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.
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.
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.
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".
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.
Table-ized A.I.
It's often business end people who don't understand the business needs for the code, and don't want to hear it.
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.
http://saveie6.com/
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.
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.
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.
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads