Software Exorcism
Mark Burroughs writes "Leave it to a SubGenius preacher to take normally mundane subjects, like software maintenance, and expose the unholy conspiracy behind them. I think the following quote from the introduction sums up the tone of the book nicely: 'Rather than shield your eyes from the sordid realities of the software industry, I am going to dust off my old 8mm films and let you take a good look at the uncensored truth for yourself. You may want to keep a paper bag handy in case you get sick.'" You know you want to read on for the rest of Burrough's review.
Software Exorcism
author
Right Reverend Bill Blunden
pages
351
publisher
Apress
rating
two thumbs up
reviewer
Mark Burroughs
ISBN
1590592344
summary
Tactics for Maintaining Legacy Code
Reverend Blunden's sermons focus on things that the college professors, in their tweedy jackets, will never talk about. As such, this book should be required reading by computer science majors, who often have a number of misconceptions concerning the industry that they are about to enter.
I doubt very highly that your instructors will tell you how to handle all the nasty little things that can occur when humans work in groups: backstabbing, stonewalling, sabotage, etc. The sad truth is that the people who do actually learn about these tactics (under the guise of "organizational behavior") are MBAs, the people who end up being managers. Folks, the deck has been stacked: The MBAs have been given whips, and the CS majors have all been given saddles. It's called animal husbandry; ... now go look up the word "cull."
Glancing at the back cover of the book, Reverend Blunden looks like the type of subversive individual that the ATF would like to have a chat with. As such, he is not one to let the reader leave without a few useful weapons (some of which may be questionable from a legal standpoint ... but hey, business is war). For example, the book tells you construct a paper trail so that even the shiftiest weasel cannot switch sides if it's suddenly convenient. Reverend Blunden even goes so far to refer the reader to a vault purveyor in New York so that evidence can be stored securely at home (hint: it's sure as hell not safe at the office). Don't kid yourself; a solid paper trail can save you during a witch-hunt.
The book also looks at how to deal with legacy code in situations where internal competition has encouraged people to hoard information, or to escape responsibility via promotion (i.e. VPs have been known to develop amnesia about the code they worked on). It explains the forces that cause these shenanigans to occur and then describes how to flush the guilty party out into the open, where their slimy tactics won't work. As before, generating a trail of evidence and possessing a degree of intellectual humility go a long way.
Then there is privacy, an issue that employers will definitely try to skirt. Management types tend to be keen on metrics to measure productivity. In addition, software engineers typically have access to code, or algorithms, that may be considered proprietary secrets. This has led many companies to monitor their engineers in some way or another (i.e. key loggers, remote desktops, sniffers, TEMPEST, etc.). Reverend Blunden provides a couple of easy, but extremely effective, counter tactics that the reader can use to foil this kind of Big Brother antics.
At the end of the day, Reverend Blunden tells it like it is. He hasn't been bought off and he doesn't have an agenda. His only goal is to warn new hires about the various landmines that exist, buried under the polite exterior of the corporate landscape. You may not like what he has to say, but no one ever said that software engineering was a pretty job. If they did, they were telling you a lie. Praise Bob.
Reverend Blunden's sermons focus on things that the college professors, in their tweedy jackets, will never talk about. As such, this book should be required reading by computer science majors, who often have a number of misconceptions concerning the industry that they are about to enter.
I doubt very highly that your instructors will tell you how to handle all the nasty little things that can occur when humans work in groups: backstabbing, stonewalling, sabotage, etc. The sad truth is that the people who do actually learn about these tactics (under the guise of "organizational behavior") are MBAs, the people who end up being managers. Folks, the deck has been stacked: The MBAs have been given whips, and the CS majors have all been given saddles. It's called animal husbandry; ... now go look up the word "cull."
Glancing at the back cover of the book, Reverend Blunden looks like the type of subversive individual that the ATF would like to have a chat with. As such, he is not one to let the reader leave without a few useful weapons (some of which may be questionable from a legal standpoint ... but hey, business is war). For example, the book tells you construct a paper trail so that even the shiftiest weasel cannot switch sides if it's suddenly convenient. Reverend Blunden even goes so far to refer the reader to a vault purveyor in New York so that evidence can be stored securely at home (hint: it's sure as hell not safe at the office). Don't kid yourself; a solid paper trail can save you during a witch-hunt.
The book also looks at how to deal with legacy code in situations where internal competition has encouraged people to hoard information, or to escape responsibility via promotion (i.e. VPs have been known to develop amnesia about the code they worked on). It explains the forces that cause these shenanigans to occur and then describes how to flush the guilty party out into the open, where their slimy tactics won't work. As before, generating a trail of evidence and possessing a degree of intellectual humility go a long way.
Then there is privacy, an issue that employers will definitely try to skirt. Management types tend to be keen on metrics to measure productivity. In addition, software engineers typically have access to code, or algorithms, that may be considered proprietary secrets. This has led many companies to monitor their engineers in some way or another (i.e. key loggers, remote desktops, sniffers, TEMPEST, etc.). Reverend Blunden provides a couple of easy, but extremely effective, counter tactics that the reader can use to foil this kind of Big Brother antics.
At the end of the day, Reverend Blunden tells it like it is. He hasn't been bought off and he doesn't have an agenda. His only goal is to warn new hires about the various landmines that exist, buried under the polite exterior of the corporate landscape. You may not like what he has to say, but no one ever said that software engineering was a pretty job. If they did, they were telling you a lie. Praise Bob.
You can purchase Software Exorcism from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
I doubt very highly that your instructors will tell you how to handle all the nasty little things that can occur when humans work in groups: backstabbing, stonewalling, sabotage, etc.
Self-employment worked for me. The boss is still a jerk, but he's my kind of jerk.
He hasn't been bought off and he doesn't have an agenda. His only goal is to warn new hires about the various landmines that exist, buried under the polite exterior of the corporate landscape. You may not like what he has to say, but no one ever said that software engineering was a pretty job. If they did, they were telling you a lie.
Ahhh, yes. Another treatise on how The Man is tapdancing on our heads.
Alternatively, we could read books on how to help create environments that are mutually advantageous, supportive positive experiences rather than focusing on heading off to another dreary color washed existence where we hate our bosses and hate our jobs.
Visit Jonesblog and say hello.
1. Tell the truth. 2. Stay out of other people's business. 3. Do the right thing.
Yes, there are some things that can't be avoided. If you are under attack by someone trying to get ahead or find a scapegoat, you have to defend yourself. But, even in these situations, there are choices.
I always save my last mod point to mod up a good troll. You people are too serious.
If the subject of the book is similar to the review, then I agree completely with the author. Computer Science in the corporate world is nothing like it is in the academic world. Something that is accurate and efficient in college is often not something that is done in a company.
The concept of politics is something that changes the meaning of the work you do at a company. In college, you are given an assignment to do. You do it, you are graded on it and you move on. At a company, you are asked what the customer wants in their software, and are not given specs. You are supposed to guess what they want. You are also never given a realistic timetable in which to do the project.
Some of those hindrences to doing a project are caused by outside forces, but most are caused by inside forces. Someone is trying to impress someone else in the company by promising something before it can be done. Or they may have their team develop a project and then release it to upper management only to find its not wanted.
Politics plays a huge role in what happens to the programmers at the bottom as well. Utimately everything that occurs to the programmer can be a result of politics. If someone cancels a project, it may be that they simply didn't like the person doing it.
At my company, we are in limbo over whether we will continue to develop a program to do something that we currently license software to do. To replace the functionality of the software will take a couple months and is nothing more than a couple of webpages and a database. We pay $250,000/yr for the outside software and can save all of that by doing it in house. The reason we are having trouble is politics. Certain people dont want the software inhouse.
Is it in the best interest of the company? No. But it's in the best interest of someone at the company. Thats a danger inside such large corporations, but it is how business gets done.
http://github.com/gbook/nidb
Here's a short version of what you need to know when you're working for someone.
Do you know the difference between a cost center and a profit center?
A cost center's something the business needs to do but doesn't make any money. Think accounting, or maintaining print servers -- the goal is to make its function as cheap as possible. One attractive way is to offshore it, provided things work out as cheaply as possible.
A profit center makes the business money. Like software development, or whatever it is that the business does: doing a good job will make the company money.
It's always better to work for the profit center.