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?
tru dat
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
...let the inmates run the asylum. I for one welcome our monkey-poo-flinging overlords!
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
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.
Reading this article I suddenly have the urge to watch Steve Balmer's Developer rap.
Guess this is meant for CEOs and CIOs. Interesting ammunition for office politics, but it's CYA time these days - not the best timing.
Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
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.
communication skills, not coding skills, are a developer's greatest asset in a bear economy
Actually, the greatest asset is the ability to claw trees to mark your territory and attract mates.
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.
Only his tendency toward a dazed stupor prevented him from screaming aloud.
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?
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.
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
These posts express my own personal views, not those of my employer
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 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.
Will working Saturdays save me, or should I take the rest of the day off and enjoy the weather?
I often don't like the choices people make, but I like the fact that people make choices. That's why I'm a conservative.
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....)
Necessity is the plea for every infringement of human freedom. It is the argument of tyrants; it is the creed of slaves.
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.
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?
There you have your biggest problem. Sending your work overseas will just set you up for an epic fail.
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
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/ for a survey on Drupal
So that's why they always start counting at zero!
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
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).
"it's not about aptitude, it's the way you're viewed" - Galinda
I don't see how the employment figures affect organisational structures and/or development methodologies.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
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!!!!
damn i took computer science as my major!!!
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
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.
So the best way to make sure you'll still be not only hirable, but desirable?
Learn Hindi.
Any sufficiently simple magic can be passed off as mere advanced technology.
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.
I didn't read the article.
At the university I work at, the number of true programmers compared to the number of project managers is about 1 to 5. There are a plethora of people who can talk all day about a solution needing a problem, the guiding policies, salaries, level of support. But surprisingly few who can churn out the code to make these projects reality. A constant complaint is the long wait for a desperately needed project, because all of the money is being spent on management and not on coding talent.
That being said, I would put forth that except in rare cases, IT doesn't know enough about their company's day-to-day doings to be included at a high level of decision making. It's up to those managers to talk to the non-IT employees in depth about their needs, then pass on the flowcharts and coding principles to the programmers who then make it into music, sweet music.
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.)
Stereotypes aside, that's basically true. Except for the programmers being poor spellers, etc. It's not programmers. It's really pretty much everyone that's graduated in the past decade or so. That might be some hyperbole, but it's not far from the truth. I mean, just look at how the 30+ crowd writes, and then compare that to today's high school graduates. It's chilling.
It could also be simply that people become better at spelling as they age.
I know I am far better at spelling now then 12 years ago when I left high school.
Another way of looking at the story of Word would be:
The Word team was the best at delivering the kind of word processor people want to pay money for.
Word, Excel, and PowerPoint are very good at the things that people who purchase software for big enterprises are willing to pay for. There's tons of features that may seem incredibly beside-the-point for the needs of a programmer. But programmers don't sign off on a lot of big purchase orders for word processing or office productivity software.
As to your other point, I would say the tech companies that survive and thrive are the ones who pull off a successful synthesis of technology and business focus. And that definitely requires a rare leader who combines talent in both areas, or more commonly good collaboration between the technical and business focused staff.
It's no healthier for the hackers to look down on the suits than for the suits to look down on the hackers. The most fun technical projects I've worked on are those where the technical folks have a real sense of how their efforts fund their own paychecks. Information flow and mutual respect are the keys here.
My video compression blog
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.
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
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.
Actually, I don't know if that particular scenario is true. I apologize.
Table-ized A.I.
The last thing a business needs is some pack of rain man coders directing where projects go.
Deep coders are too hyper-focused to understand business needs and the people running the business are too focused on that to understand the code.
In the real world where jobs depend on money and deadlines there need to be abstraction layers between the people writing the code and the people running the project.
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
I'd like to buy homeland for our 10 million people. http://twitter.com/mahadiga
It's often business end people who don't understand the business needs for the code, and don't want to hear it.
Don't forget the VP (Exec, Senior, Junior, Associate) and Director layers!
The management bunch would call what you say heresy because it reduces or eliminates the need for their services.
Imagine that, a self-directed team reporting directly to the CTO. This is how OSS projects get run, by a small, subject-matter-expert team leading a large distributed one that does other things than work on COBOL (heh!) all the time.
Her lips were softer than a duck's bill, but her quacks
then when there is a crisis, all you will have left is generic coders.
Not much help with the problem is some obscure interaction between your three programming languages, two databases, and several other major packages include MQ, workflow, etc.
Personally, I think the applications are written in too many languages to master these days.
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
The worse I.T. performs the stronger the case to outsource as its now viewed as an entity that sucks up money and adds no value.
What is the future? 15 years from now I see everything done via www.salesforce.com and Google Docs or similiar kinds of hosted apps in China and India.
Servers are out and internet replacements are in. I.T. is a sinking ship. I hate to say this but its true. The cost savings for outsourcing to internet apps like salesforce are HUGE and where are the system administrators and programmers going to fit in? They don't. The hosted internet app houses will have them. You don't need architects designing your office buildings on staff do you? Rather you rent out.
Once data is stored overseas it will create lock in making it impossible to leave.
Time to learn more skills as computer techs and cisco engineers are going to be all that is left in about a decade when everyone switches.
http://saveie6.com/
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/
I worked in a job where my programming skills didn't matter. I'd solve incredibly complex problems created by the incompetence of the boss.
He didn't care! But if I updated the webpage, all was well in the world.
I was fired days before the biggest crash of the stock market's history, not too long ago. It looked bad.
But I did get a better job, and you can too, if you're in that situation. Don't keep yourself in a situation like that, or you'll be their scapegoat. Nobody benefits from that.
If you can read this, I forgot to post anonymously.
We had to let one of the nicest guys ever go because the work we needed him to do went way over his head. We tried to find something else for him to do, but there simply wasn't anything that he could pull off with any quality in any realistic amount of time.
Soft skills are all very well and in the end both soft and hard skill sets are necessary, but the know-WTF-you're-talking-about kind comes first.
Bitten Apples are still better than dirty Windows...
I'll tell you what's chilling: a whole bunch of schools these days teach "whole-word reading". This turns English into Chinese.
Instead of teaching the basic phonics, so that a student can "sound out" any word she/he has never seen before, this idea is that the student should learn to recognize a whole word as a gestalt. If you visit a primary school and see posters where there are words surrounded by outlines that emphasize their shape, you are in a whole-word school.
If you don't know the phonics, learning one word doesn't help you learn another. It's just like Chinese, where you have to memorize all the words as pictures. (It's a pretty close analogy; the Chinese for "ice" contains the Chinese letter for "water", just like the word "therein" contains the word "there". But learning "there" doesn't help you learn "theatre".) It's actually harder to learn whole-word English than Chinese, because English can be written in capital letters, or italics; while Chinese letters are always written the same way.
This disastrous idea came about because someone studied adults and found that most adults have learned to recognize words as gestalts. Why not, then, teach the young ones to do this? Just skip past that wasteful phonics thingy and go straight to the productive whole-word reading. But this isn't really the best for kids, as many studies have shown.
Kids need to learn the phonics, to give them the tools to tackle words they have never seen before.
Thank God I was taught phonics when I was young.
Teach the kids whole word reading if you must -- AFTER they have learned their phonics. Young kids have sponges for brains and can learn more than one way. Just give them the phonics tools they need.
http://www.halcyon.org/wholelan.html
Someone said earlier: "Programmers are neither abstractly creative nor socially comfortable by default"
I really have qualms with this. Software is not like other discplines. The real fact of the matter is most programmers are poor in math and computer science AND many programmers didn't have early hardware to tinker with.
Andre lamothe was so frustrated by coders lack of understanding of hardware, math and algorithms he started his own site.
http://www.xgamestation.com/index.php
IMHO I would have killed for a site like this when I was younger, in the 'pre-internet' days when I was still in highschool. Personally our real problem is that kids are not guided where they need to be and everyone thinks they 'know' what a software engineer needs to know when they don't.
It also doesn't help that many technically inclined kids are ostracized because they happen to be interested in sciency or electronicy things. Not to mention some coders surely need some social skills classes as well as weight loss classes (to boost their social skills confidence).
Personally if I were running a business I would pay bonus's to coders that went to toastmasters, etc and improved their interpersonal communication skills. Businesses just have to start demanding and REWARDING this from their workforce if they want to see it. The problem is business's treat coders/programmers like unskilled laborers to be used and abused for the lowest wages possible. Is it any wonder that no one really wants to improve given the sorry situation in software development?
The best coders I've ever met were tinkerers. They sat there and tinkered with shit for hours plugging away exploring their curiousity. They had an overwhelming desire to master their discipline, and many were also mathematically inclined.
Electronics, math and coding have a lot in common, there are deep relationships between electronics, coding and math. The problem is you will not find most or all the skills to run a business well monolithically in one person, since the education system is set up so poorly.
I've found that regardless of the pace of development, many folks simply don't document their code, or do so poorly.
That's true. It's an unfortunate consequence of the fact that a lot of development groups have never really stopped to consider what effective documentation actually is.
I always find it odd that even though heavy, waterfall-model development processes have been well criticised today, a lot of places still view documentation as if each project must have a big, formal requirements spec, functional spec, design spec, various test specs, or whatever we choose to call the equivalent documents, all written in the proper order ahead of time, and with so much boilerplate that it takes more space than the useful content for smaller projects. If you look at the participants in the development process and their respective roles, the kinds of information that are actually useful to each participant, the people who can provide that information to their colleagues, and for how long each kind of information will remain relevant, then the waterfall-esque documentation chain looks about as anachronistic as the waterfall model itself.
Moreover, the trendy shops that like to use terms like "Agile" are almost as bad: there seems to be this strange view that the way to avoid having all of that heavyweight documentation is to have little more than a roadmap, a bug tracker, a textbook example of how not to write coding standards, and a documentation intranet generated from source code comments. Hey, don't mock the auto-generated intranet, it never gets out of date! Of course it doesn't, because it typically contains no original content.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Pair programming is hard. If you just put two random programmers in front of a computer, they will probably not work much magic.
If you learn it from people who are good at it, it is an incredible productivity booster.
I think that the more layers of people that there are between developers and users, the less appropriate or useful the product will eventually be.
This is all just my personal opinion.
Business analysts should be different from software engineers which should be different from code monkeys. The business analyst communicates with the customer, helps them understand their needs and plans the high level functions. The software engineer takes the input from the business analyst and converts it to a high level description of code. A code monkey takes the high-level description of code and turns it into actual code. The quality department makes sure all the above work within company procedures and the result product is within specifications.
The above model works for most cases. Small projects can have many roles fused into one roles, for economic purposes. But in general, it is not possible and even desirable to make people jump from one role they are comfortable with to another. The result is catastrophic.
For example, I enjoy tremendously designing stuff, that's why I am a software engineer. I like to take decisions, and therefore I would not like it if I only was a code monkey. But I certainly hate all those pompous managers with their SUVs, expensive rollexes and suits, that 90% of their talk is about their image. I don't wish to hang out with those people, and although I have communication skills, I am not willing to spend my valuable time in being a hypocrite asshole. Therefore, I am not the right person to be a high-level manager. But I understand that when it comes to money, people activate all their instincts, and showing off plays a big role in persuading others to give you their money...
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.
I'm a coder. I sell myself on the programming languages I know and the technologies I've used because that's what the employers think they understand.
If you want me to write a Java application I'll spend a few weeks learning the language and be reasonably competent. I'll need to explain what my code does and understand what people want the code to do.
We understand that. Managers seem to be clueless.
that communication skills, not coding skills
Most of the problems with large coding projects isn't communication. It is organization. And to think more people talking competent English will automatically help organize a large coding project, is missing the target.
Communication isn't an asset, it is a requirement for anyone working with other people. But most people can communicate. Coding on the other hand, is not measurable by the same kind of spectrum for measuring communication. A competent coder can do the job of a 20 person team of average coders in half the time. A competent coder can do things others simply can't. They can also write simple, structurally sound code. Someone with broken English might still be able to communication, but in any commercial project, there is absolutely no room for broken code or broken coders.
If you can find a competent coder that can also manage his own "code monkeys" to accelerate their work, then you have a true gem. Hire that person and pay them half your budget for the entire project. Make them work 70hr weeks until the project is done, and then give them a long vacation twice as long as your sales team reaps the profits.
Of course, most companies don't understand where they generate their value. Much like the overall economy the company has continued to make money in spite of their management, not because of it.
Unfortunately the barrier to entry for newer and more efficient companies in any given product space is the lead time the established company has in product development, and the requirement that any newcomers understand the business well enough to do it significantly better than the established company.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
All I could think of was the same tired old mantra that programmers need to forget about technical expertise and learn "the business".
Computers don't execute "communications" and they don't execute "the business". They execute CODE. Someone, sooner or later has to produce that code. Whether the coder speaks "the business" or not isn't germane, providing someone somewhere can bridge the chasm between business requirements and actual executable software and procedures.
I think there's a basic fallacy in the concept that the programmers are part of "the business". More correctly, programmers are in their OWN business - the IT business, and their employer is their customer. Part of good business is customer satisfaction, so it behooves IT to work work WITH the business. But IT is a very complex business in its own right, and expecting people who've invested a lot of time and effort in becoming IT experts to dilute their skills by being business experts as well doesn't sound efficient or productive to me.
There is a place for someone who can bridge the gap between business and technical. In fact, there used to be a whole job category for it - the Systems Analyst.
We're all so keen on self-service and eliminating redundancies these days, but face it. Most modern-day software is crap. Maybe there's a good business case for a few "unnecessary" intermediaries. Rather than degrade the product by attempting to ram a bunch of anti-social misfits into a social environment, maybe what we really need is to consider that anti-social misfits have their uses, too.
its titled 'coders your days are numbered', but boils down to saying totally the opposite.
its evident that the article writer doesnt know jack shit about how outsourcing really works. most of the time client comes directly to overseas developer, saying 'i want this, make it happen'. its nothing like 'deliverables blabberables then grunt work is outsourced'. that may only hold regarding mega corporations. but then again what is their volume of outsourcing, compared to the total outsourcing ?
come to terms with it. there is no outsourcing - internet is another nation by itself. and people get the work done by whomever they prefer. that mostly boils down to reliability + confidentiality + price.
there is nothing barring american developers from adopting the same methods that are utilized by indian, and other overseas places successful in outsourcing. your only problem is your high cost of living. yet, i have been informed of a handful of individual developers who are able to outbid indians and still make a decent living.
Read radical news here
Neil McAllister does not explain why companies would want to push the design down to the developer, he simply asserts that it is so. As a developer, architect and system engineer who believes he meets the criteria of a good communicator, I find my self in the job market again after being "resource actioned" (laid off) by IBM.
Perhaps IBM is not a software house but what I see happening at that level is the dependence on system engineering (managing requirements, being able to trace features to requirements, understanding what the "customer" wants) means that the developer is not in demand the coder is. The system engineer (SE) converts customer requirements into application specifications that the coder implements. The coder need only understand the language of the specification. The coder need not be "on shore". The project manager, who manages the development schedule, should be with the coders.
That leaves the SE as the communicator, designer, the "developer" in Mr. McAllister's article, as a travelling salesman. Travelling to customers, meeting them face to face to understand what they want, documenting, specifying and shipping the spec offshore to start the cycle again.
So I should put that 18 in to charisma, and not Intelligence?
On Wall Street they say "buy low, sell high" On the pad we say, "buy high, sell high" Isn't that somehow better?
I number everything. Don't you? In relation to days it's called a calendar.
There is nothing stopping you, right now, from forming your own exclusive club -- or "professional association," if you prefer -- and marketing it as the only place to go to get qualified developers. My guess, however, is that you don't wish to stop there. Rather, you most likely would like to go further than free competition would allow and restrict competition through laws forbidding independent programmers from competing.
Please keep your proposal for what amounts to a medieval guild to your fantasy role-playing game and leave the grown ups free to make up their own minds when it comes to whom to hire.
quiquid id est, timeo puellas et oscula dantes.
He wrote several boooks predicting the end of programming unless yo programmed jst like him
True story. I take over an app. Enough changes were required that a rewrite made more sense. Done. Single developer, albeit slightly high salary. All the users are happy. Management thinks lets try this new outsourcing thing to India for some new functionality, very focused, specific, uncomplicated effort. I figured (me knowing nothing about complex Word macros) I would probably take 2, maybe 3 weeks without much business people involvement. The "certified" MS developers (3-4) in India after 3 months, 10 bug-filled releases and dozens of hours of biz people involvement finally delivered something that more or less worked.
Somehow this was considered a success. They decide lets hire a bunch of outsourced staff and replace me because they could get 3-4 people at what they paid me. Well after a year or so of unhappy clients, missed or buggy deliveries, etc, I get a call to undo the mess they made. I discover none of the new features they were supposed to deliver worked so all that time and money was simply thrown away. Fortunately since my initial departure I had been working for another division directly (not via IT) that recognized that I was a valuable resource not to be lost.
Six years later, history repeats itself. Another IT-driven outsourcing "effort" has been in the works to consolidate 3 applications, now it's 2. I've just been informed they are over another year behind in developing phase 2 which would bring it up to 2.5 years behind. Phase 1 is still not acceptable. I'm also more or less being told not to further enhance my app, twiddle my thumbs. Can you just see the savings?
I happily see some small, specialized groups efficiently delivering quality and sadly I see repeated efforts to outsource to people that have zero knowledge about the biz requirements which results in waste of time and money. Management needs to get it thru their thick heads that developing apps cannot be treated like making shirts. A seamstress is a seamstress is a seamstress. Maybe the stitching quality is a little different, not as straight, etc. It still functions as a shirt. An application is not that, if the code is crooked either the results are flawed or it simply doesn't function.
Sounds right to me. Let's make it open source so NOBODY gets paid for coding anything! Corporate America should love that.
If communicating is so important for developers, then why are US companies breaking their necks to offshore all of their development jobs, or to replace US workers, with guest workers who barely speak English?
shouldn't mock those who believe they are too.
"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."
So I guess on the slow days, you consider minor issues like program correctness.
Two reasons for pair programming:
1) Catching bugs, feedback
2) Making it so the primary programmer (the one with the keyboard) can be replaced/fired.
The problem is that it is easy to count money and difficult to measure quality.
"We going to save a xxx$." - that goes down like honey.
"We are loosing a xx% quality." - so what.
the theory of Agile is all well and good, but bears little resemblance to its actual practice other than in surface level features.
Real shops use the parts of it that justify what they want to do, and ignore the parts that don't.
The shops I know that use it, look exactly as described. You sir, can research to your heart's content -- it doesn't produce better code.
The problem with quotes on the internet, is that nobody bothers to check their veracity. -- Abraham Lincoln
The record simply disagrees with you. While there may be many pretenders out there, a good Agile shop will probably be the best contractor you can find.
As I have already stated several times: your mileage may vary. But overall Agile has been quite a success, and deservedly so.
I think there should be resource pool of programmers and designers and analysts and project leaders. Sure it helps if a manager understands the technology, but that means better communication to both directions. Giving too much responsibility to programmers is not a good approach either.
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.
I've found that the ones who don't crack a sweat in church are often the biggest whores of them all. Difference being, they feel justified in their whoring. Applied to public speaking, you have to be comfortable in your whoring to speak in front of people, and toastmasters or any place where you can stand up and practice the art of the speech is a good idea.
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.
Of course he did, he's a philosopher. He also fantasized about dangling virgins, but I like my women lusty and alive.
"We returned the General to El Salvador, or maybe Guatemala, it's difficult to tell from 10,000 feet"
I'd listen to my senior coworkers but it's hard to find workers that have more than 25 years experience.