The Pragmatic Programmers Interviewed 162
jpkunst writes "An interesting interview at the O'Reilly Network with Andy Hunt and Dave Thomas, authors of The Pragmatic Programmer, who recently started their own publishing company. Many topics are covered. Dave has this to say about outsourcing: 'To get job security, developers need to position themselves as highly effective business-value generators, working with the rest of the company to solve common goals. If you sit in your cube waiting for a spec to be thrown over the wall, then you may be in for a wait -- that spec might be in an envelope on its way to Bangalore'"
outsourcing (Score:1, Interesting)
there's so much hype going on, but the fact is that only some 0.01% of all jobs are being outsourced and the chance that you'll loose your job over it are practically nil. you're more likely to loose it by being incompetent (this is pretty common these days.)
haha (Score:2, Interesting)
In other words, developers must try to become gods.
Suckups :P (Score:2, Interesting)
It's inspirational... (Score:3, Interesting)
"Don't repeat yourself"
Durr.
"Think about the kind of work that can be effectively outsourced (where "effectively" is used in the context of some manager's opinion). Can they ship stuff offshore that can be specified down to some fine level of detail? Yup! Can they send repetitive, rule-based, highly constrained stuff overseas? You bet! The stuff that will stay is the stuff that involves more intuition, and more interaction. To get job security, developers need to position themselves as highly effective business-value generators, working with the rest of the company to solve common goals. If you sit in your cube waiting for a spec to be thrown over the wall, then you may be in for a wait -- that spec might be in an envelope on its way to Bangalore."
It's fun maintaining code from India. It's also fun to tell your customers and your boss what the program should do. You should try both sometime.
"Explain how agile processes can reduce risk. Explain how lightweight approaches can earn value faster. And explain how they should outsource the mundane stuff, and leave their talented pool of in-house developers free to work on the next revolutionary change to the company's business."
These are the same people that advocate nightly builds and all that other crap that just gets in the way. All you have to do to make a software project successful is have at least two people who don't suck at life working on it, and have them delegate the boring work to the people who thought going into computers would make them rich - all consultants do is take common sense and dress it up so it sounds good to management, and in turn, management gives them a shitload of money. I've never heard of a software house suddenly turning around and not sucking because "we hired a consultant, and his strategy was fricking awesome, and suddenly we were making products that like didn't suck, and it was pretty cool." Managers only hire consulants if their teams aren't making the numbers they should, so they can therefore justify the lower productivitivy of their teams by saying that they're "adapting to the new vision/strategy/paradigm," and that's usually enough to buy them a year of suckage until upper management wises up - and knowing upper management, that rarely ever happens.
Performance really doesn't play an issue in outshoring to India - if your job's so simple a monkey could do it, your job's going to get outsourced, regardless of your performance. You can't really match cost efficiency of someone who lives in a country with 1/10 the per capita income. All you have to do is pray for the language barrier and hope the companies who are employing offshoring all get burned when they need to maintain the code - I think it's a fad, but I've been wrong before.
Re:Specs (Score:1, Interesting)
It is very easy to over invest in design. You say 'surely you aren't trying to dive into the code before the design is complete', but I ask you how do you know when the design is complete? If your coders are in the same office helping with the design it may be 'complete' (meaning it has reached a point where further investment will not increase the likelihood of sucess of the project, and will simply waste money) much sooner than it will be 'complete' if you are shipping it off over seas to people who will have to deal with a language barrier and a day long delay in communications.
Spending the extra time to make the spec usuable under these circumstances is extremely likely to cost more than what you are saving by outsourcing development. Outsourcing will only really become cost effective when design is outsourced along with coding. Seperating design and implementation completely is fools errand.
And in response to 2), if you have class diagrams and a list of the specific methods to implement and all input/output from each then perhaps one persons code will be close to the others, but you still have issues of inproper formatting, odd local variable names, no commenting, etc. All of these have a huge effect on the cost of a project long term. And if you don't have design down the the class diagram, function description levels before you start coding then the quality of the code will be completely dependant on the quality of the developer as he makes these decisions himself. If I tell two coders I want a for loop from i to MAX_LEN, then yes they probably will write equally good/bad code. But if I tell two developers we need a class to represent this business object that needs to have these types of actions taken on it, then I will get very, very different code from each. One is likely to be much better than the other. Knowing you have a GOOD coder gives you the luxury of not having to design down to the finest detail for him. A good developer should be involved in design as he implements and will save the company time and money because a seperate designer didn't have to do everything for him.
Maybe you would argue you should always have this level of design, but the fact is if you have GOOD developers, who are LOCAL, and in constant COMMUNICATION with the CUSTOMER then you can save an enourmous amount of money by not taking design to this level before beginning to code. Overdone design is useful to make an incompetant programmer still manage to write something functional. But it is a complete waste of money if you have good developers.
Most companies stand to save money by doing LESS design because they have GOOD programmers. I'm willing to bet that for 80%+ of projects inverting this and doing MORE design to make up for BAD programmers will cost more.
Save money by not offshoring (Score:5, Interesting)
We hired some chimps from a huge international consultancy. The document they produced is so piss-poor we are on our sixth draft. In the time this has taken (2 months) with two very expensive consultants working full time and two in-house developers checking their work part-time, we have
The threat of offshoring has been massively over stated. More and more companies are seeing that this process (send the requirement to India) is simply not cost-effective. It may take some time for all PHBs to see this but it will happen. That's business.
There is (hopefully) a happy ending. The outsource providers tendering for this gig are charging in the region of 700UKP/day (about $1200/day) for a Java programmer with about 3 years experience (I'm not making this up). Most say that they can cut that cost by about a third if we offshored. Well, gee, that's still more expensive than hiring some local contractor with 7 years experience who can sit down and talk to the business people. We're getting "buy-in" from management to save money and not offshore. We'll have a decision soon and it looks good.
Agile methodologies will be the saviour of the Western programmer.
Re:you wouldn't know what positive thinking is (Score:1, Interesting)
Based on that sentence, I can only assume that you don't know the definition of the words that you are using. Where do you intend to work, if not in the workplace?
Re:you wouldn't know what positive thinking is (Score:3, Interesting)
I already know how office politics work:
Day one: New employee is hired and is viewed with some combination of envy and ambivalence by the smiling co-workers in the nearby cubicles.
Day Four: New employee dares to open their mouth in a meeting, offering a new idea for some problem the current workers haven't been able to solve. Management idiot nods his fat head. Co-workers' envy turns to burning hatred and hostility while their smiles grow ever-wider.
Day Five: Co-workers begin to plot eventual firing of new employee, constructing an elaborate campaign of complaints, both formal and informal, political backbiting and openly challenging the new employees' ideas in meetings.
New employee is a) powerless to stop the inevitable, because they have no friends at the company yet or b) hopelessly naive, believing the liar cheat fuck bastards who smile and invite them to lunch at the local yuppie grill, where they will feign interest in the rest of the new employees' worthless ideas.
Day Eight: Constant complaints have begun. New employee becomes isolated and useless, since nobody will work with them. Management begins to complain. The words "team player" are slowly beginning to slither into conversations, like wet submerged shit.
Day Eleven: Lunch invitations have ceased. New employee is no longer invited to meetings. HR begins to complain about the new employee having shown a "continuing pattern of lateness to work" (a pattern somehow established in only ten days) while ignoring the average 75-hour workweeks the new employee is working. Management is now showing open contempt for the new employee, while offering no suggestions other than "please show up on time." Co-workers refuse to speak at all.
Day Fifteen: At 8:07AM, new employee is greeted by no fewer than three security guards at their "desk" which has been dismantled completely (to enhance the indignity, of course). They are hurriedly forced to gather whatever meager posessions they have (being instructed in writing, nobody speaks to them at all), they are escorted to the door and physically shoved into the parking lot.
Four months later, they are mailed their only paycheck.
This was a company of several hundred people and a department of more than 70. I saw this happen to THREE people before I quit. One of those fired had just closed escrow on a new house.
That is office politics, and there is no way I would ever participate in it.
Yeah, that reminds me of an old story (Score:5, Interesting)
So I was a low level guy, and a new guy on the block to boot. I've done a quick evaluation of available tools and the only thing that could accomplish the task the way I liked it (and the way it made sense) was Mercury Interactive Load Runner. The only problem was - it was $150K for a license, and nobody was going to spend this kind of money on performance.
So after whining to the management for a while, I sat down and wrote my own replacement for this $150K tool that did all I wanted.
You know what happened next? You've guessed right, I got attacked by the management, Dev manager in fact (I hope he burns in hell when he dies). And dev manager and product unit manager were pals, so no matter what I did, the Dev manager would have his smalltalk with PUM and bring whatever I was doing to a grinding halt.
I've done this thing anyway (weekends, overtime) and shipped two versions of this god damn product with it. Dev manager eventually got fired for not being careful enough with his language when talking to customers.
My career got screwed, though. I only got one promotion on that team despite busting my ass REAL hard and delivering world-class "business value".
The moral of the story - you either fuck the product and do what the management says, or you fuck the management and yourself and do the right thing. There's no third way out. The way I see it, it's always better to get fired for doing something than for doing nothing.
Re:Specs (Score:3, Interesting)
I don't know about haystor's individual case, but in our department, the detailed design currently is the code. I got handed some detailed designs to review the other day, and several of them were literally 15 pages of COBOL code with a few titles between them in a Word document - the idea being very much that we can now ship these "designs" off to India to "code" (i.e., cut and paste) from. I'm all for properly structured design - not just diving straight into coding - and if there's a section in a detailed design that does need a specific piece of code written a specific way, then maybe a few lines of an actual code sample may not be a bad thing, but having the entire program written in a Word document by one person, and then pasted into a COBOL editor by someone else is a bad (and very wasteful) thing.
It also makes outsourcing self-perpetuating - "You lot took two months to design this stuff. Those outsourcers coded it up in a couple of weeks" - I've actually heard that arguement used by managers. Well, duh. I think that two weeks to cut and paste someone else's code is pretty shocking, myself.
Do you think you can do a better job writing "for (int i=0; iMAX_LEN; i++)" better than anyone else?
I don't, and in our case, that's pretty much the point. Our designs would be expected to contain "for (int i=0; i<MAX_LEN; i++){....}", rather than "check that each element contains at least one item" or whatever, and the point about identifying bugs is spot on - if you're writing and unit testing the code based on some description of the intent, then you may well spot where you're looping too many times through your code (because it doesn't do what you expect), whereas when you are writing the code in the document, you can't test it, and by the time the doc arrives at the coder, all he sees is a for loop - he doesn't really see the purpose of it, how it fits in the bigger picture etc, so he has no idea that it should actually loop one less time. Sure, comments could help, but when people are being pushed on deadlines, source comments in the document are being seen as the first thing to go, and as these docs aren't code reviewed ("that happens during the coding phase", I've been told), the lack of comments is not usually spotted, and as the designers are being measured on how quickly they can get these documents produced, and whether they contain enough detail for a coder to pick up and use, rather than whether the document is accurate, guess which option they take.organizations - big and small (Score:3, Interesting)
Small organizations: take on the strengths and weaknesses of their leader to an almost pathological degree. If weaknesses outweigh strengths (which is most often the case, especially someone with the force of will and ego to start their own organization), it becomes like living in a dysfunctional family with very difficult parents.
Assuming you can deal with the inherent risks of small company life (they can go under, they're not usually prestigious, and they don't offer traditional "job security" of a nice bonus & severance package), this probably is the easiest way to avoid bureaucratic politics, though you'll have to deal with the more intimate personality conflicts that tend to arise.
Large organizations: All large organizations, whether corporate or public service, seem to be obsessed with "mechanizing" their structure and processes. It's an irrational form of rationality. They don't look at their task, what the purpose behind the organization is (it has to be more than "profit"). Through this, they sow the seeds of their own destruction.
Such organizations inevitably become politicized and split by bureaucratic and technocratic interest groups, unless top management keeps re-enforcing & renewing the organization's purpose -- having a reason for existing: a goal, a mission, something that transcends the power-politics and aimlessness of "profit maximization". Of course, this never lasts. But it is the moments of renewal that matter -- that make organizations worth working for.
What's a techie to do? Nevertheless, in a politicized organization, which seems to be what you have the most experience with, Machiavellian tactics are what tend to be the only effective course, in the large, anyway. Being staff, techies can't really play at this, they can only line up behind a player and hope to contribute their talents & knowledge to the organization without getting too caught up in the struggle. Your best bet is to try to pick a faction that somewhat shares your values, and have a team & manager with enough upper management factional support to ensure you're somewhat protected from the politics.
Of course, none of this is easy to find -- the best way is through having a network of techie friends, hoping that someone lucks out. This is why you usually see "changing of the guards" in any management firing & re-org
Anyway, the above is a bit of anecdotal, but some of it is based on real organizational theory, which might help you understand the utter pettiness that tends to devour many of our institutions. (I'd suggest some Henry Mintzberg to start).