Slashdot Mirror

XP, Scrum, etc. have some good ideas--however, as TFA mentions, they require *thought* to implement well. They are also not new, just re-packaged. Ed Yourdon was talking about interviewing users to find out how the system/process *really* works over 20 years ago. (His "Structured Analysis" is an excellent on-line book for learning how to design systems)

However, any method that relies on your team members being in the top 10%/experienced programmers is only going to be useful for a few, high-profile or specialized projects where you can actually hire or have available those top, experienced programmers. What the world really needs is an "Army method": something that gets useful, productive work out of any coder who isn't literally retarded. You won't get that with any method that leaves the design specs between the lead programmer's ears; the average person needs a road map and instructions. However, with sufficiently detailed, simple step-by-step instructions, a hick fresh out of high school can maintain a tank. The same thing is true of the "average" coder: with adequate design specs, any idiot who knows how to code can be productive.

The trick is coming up with those design specs, just like the brilliance of Army training is in designing the courses and instructions that enable any idiot to repair a tank.

The Mythical Man Month - Fred Brookes
The truth about project management. Written in 1975 and we still haven't learnt.

If you like the The Mythical Man Month, you'll love the 20th Anniversay Edition, in which Brooks candidly reports where he was wrong in the original.

He sticks with his thesis that there's no "silver bullet" to speed up software development but he admits his project planning advice has been largely superceded.

The book is still indespensable but I would add one other revision to his thesis that large projects are fundamentally different from small projects. For those of us who are only involved in small projects, it is interesting how much of what he describes applies to writing a 10-line shell script.

I think Slashdot ought to do a whole story on people's experiences with Project Zombie, ill-conceived, the living undead, Death March, etc.

Management always trumpets success and ignores failure - but how better to learn how to avoid failure than to have examples of it dissected in front of you?

I'll suggest everybody who has not yet done so should RTF precedents for such a study...it is as ancient as it is true: Brooks "Mythical Man Month" describes the reasons projects blow up pretty well. For all the technology heaped on software development in the 30 years since the book came out, very little has changed: Software projects are complicated beasts attempted by mere humans. Steve McConnel's books will be more familiar to /. readers and his approach to project management tries to head off the "changed requirements" fiascos with a feedback and correction mechanism of frequent critical project reviews...I wonder if that actually has worked for anyone:-(

You have it *exactly backwards*, my friend. If there weren't so many people in the field, they'd be able to handle less volume, and be much more expensive. Outsourcing would have happened much faster, in greater quantities, than it has.

Well, I don't have it exactly backwards, but I can see your point. Still, the most expensive programmers are the cheapest.

To explain/support that statement, let me point you at This paper about Superprogrammers or, the much shorter Jargon File entry. It is claimed that some programmers are at least 1000% faster than the slowest. I claim a $80k/yr programmer will get more done (and is thus cheaper) than 3x $40k/yr "should have been lawyers". It reminds me of the saying "an engineer can do for a dime what any fool can do for a dollar". Compare/contrast
This Microsoft site where they think "good tools and processes" will level the field. I've got my doubts. Sounds like Microsoft hired a lot of those lawyers.

Of course, that might not have the effect my ex-coworkers would like, since the book is about how to survive Death Marches, instead of how to avoid creating them.

If you are in a windows shop, you are way understaffed for what you do. If you are in a unix shop, you are still understaffed.

What I try to do is:

Fix broken things that cause the most problem for the most people (or will cause the most monitary loss) first

Fix "quickie" problems next

New things for the most people

One day a week (or a half day) do those routine things that affect everyone, virus updates, IDS updates, patches, yada yada yada.

Try to keep reserve time in the morning and afternoon for high priority things that aren't schedueled, but don't tell people that's what you are doing or it will become the catchall time everyone ratpacks you.

Seriously consider that you've gotten an impossible mission here. Sounds like your employer isn't serious about taking care of the IT workload because they see it as an expense with no return. Point out that while you don't normally make or break any one thing, the IT department makes every one else more effeciant and that by properly funding and staffing IT they will save money or gain effeciency everywhere else, thus saving money everywhere else. Have situations where you can show them with in their own shop that what you've done saved money, or allowed something to be done faster. One good way to do this is to enlist others on your side.

Pick out a person who is not too good with computers, but does something that has very concrete and positive results for the company. Adopt that person, and make sure they get what they need. Ask them to help you make your case to management after a while.

Remember, it's only a job. While IT people as a class normally will do insane things to make sure everything works, take care of yourself too. After all, you were looking for a job when you found this one, and I bet the last person quit/was fired due to burnout.

Two books that I've read come to mind that deal with this sort of "omg wtf 12 hour days stupid management" deal.

The first is "Death March Projects" by Edward Yourdon. The book deals with so-called Death March projects that everyone expects will end in failure (and similarly doomed situations). There are several sections on how to cope with situations like 12/7 work situations (as well as how to avoid them, but those passages might not be too useful at the moment). The book is interesting and (especially if you've never BEEN in a death march project) rather entertaining. Available at a local University library near you. Roughly 4 hours to skim through it.

The second is a book that should be on every programmer's bookshelf. I speak, of course, of "Code Complete" by Steve McConnell, the manual of 90s programming (when widescale 12/7 programming enforcements took place). In addition to much useful content about creating software, the last few sections deal with how to manage the product team, including help on how to deal with situations such as an enforced overtime. And yes, I know the book is published by Microsoft Press, so go ahead and post "ha-ha MS sux" and all that, thankyouverymuch now please sit down, because this is a GOOD book.

I highly recommend reading both these books, and keeping a copy of Code Complete handy. Now, as to when you'll find the TIME to read such things if you're working 12/7... all I can say is, I have no idea; I'm just a CS student, so I have plenty of time.

To all you genius programmers: you're good. But are you good enough to outhack half a dozen Chinese guys working for half your salary?

I predict that within 10 years, half the US programming market will have gone to these overseas firms.


Been there, done that.


Ed Yourdon's "Decline and Fall of the American Programmer"

and the sequel

Rise & Resurrection of the American Programmer

To all you genius programmers: you're good. But are you good enough to outhack half a dozen Chinese guys working for half your salary?

I predict that within 10 years, half the US programming market will have gone to these overseas firms.


Been there, done that.


Ed Yourdon's "Decline and Fall of the American Programmer"

and the sequel

Rise & Resurrection of the American Programmer

Cheez-Wiz, this paper doesn't sound anywhere as glamorous as those 'Lincoln Tech" ads on late night television promising me millions of dollars and pretty women. Foo!

Actually, it is interesting to see he starts out with debugging -- how many of us have seen wanna-be programmers come and go when the project hits the dreaded maintenance cycle. Provided of course they can make it through the Yourdon-esque death-march.

Several years ago when I found myself on an understaffed tightly (insanely) scheduled project I, and several others on the project, read _Death March: The Complete Software Developer's Guide to Surviving "Mission Impossible" Projects_ by Edward Yourdon.

Summary from Yourdon's site

I see a lot of Yourdon's advice in these /. comments. Basically to know what you are getting into and do it with eyes wide open. There are both reasons to do it (money, foot in the door, etc) and reasons to run away, but your most important time to negotiation is before you say "yes".

This follows the classic theory taught by Mel Brooks in "The Mythical Man Month"

You misspelled Fred Brooks.

Although I do think that Mel Brooks could do something fun with the topic...

Ed Yourdon has written two books and as he was writing/editing them he posted the chapters on his web site. Then, when the book was done he took the contents down.

As for novel individual marketing strategies, I would have to agree that more people should individually create and market materials thereby disintermediate the big greedy corporations who will ultimately deprive us of our fair use rights.

I think you meant Ed Yourdon, author of "Decline and Fall of the American Programmer" and also "The Rise and Resurrection of the American Programmer".

Huh?
Going by the (nicely written) review, it seems that this book might be of interest to newly-unemployed MBAs and PHBs, trying to understand what the **** hit them.
Not much in there that would be of interest to the typical /.-er, going by the review.
Perhaps if the book would have been written by Ed Yourdon...

Productivity: A Personal Choice

Chief Programmer Teams

Intermittent Aberrations: Can Mature Companies Innovate?

How to Defend an Unpopular Schedule

This guy still cracks me up. Imagine burning off all the built-up goodwill you've been collecting in a single massive non-event. It's really too bad, I enjoyed his books.

Dancin Santa

What, you're ever at a computer without access to TMMM!? :-)

Brooks does mention two mice, but has no pointers to further info. In Chapter 19 (pp. 261--262 in my A-W softcover edition), the section ``Command utterances and the two-cursor problem'' discusses how most commands consist of a verb and a noun---action and object---and how convenient it would be to use two cursors to simultaneously select each. The notes for that chapter are prefaced with ``Material quoted without citation is from personal communications.'' The note from that subsection, says in its entirety:

7. It appears the Apple Desk Top Bus could handle two mice electronically, but the operating system provides no such function.

If you haven't read this book, do so now. If you wonder why, you might check some reviews:

• A collection of reviews at Softpanorama.org. Covers more than just TMMM. Well worth checking out. The general site looks very interesting, too.
• /.'s own review. If anything, understated.
• Ed Yourdon's brief commentary, with an interesting sidelight on how the book got updated.
• Fatbrain.com's sales page $25
• Bookpool.com's sales page $24

...Yourdon's web site, all about software development process, software project management and other "software issues", gives me an "Error: do you wish to debug?" message when it loads. If a guru can't get things right then what hope is there for mere mortals?

...richie

Click Here to get Ed Yourdon's assessment of the Y2K situation. Ed is a noted software engineer, author of "Decline and Fall of the American Programmer" and one of the more influential Y2K doom-n-gloomers.

There may be some problems in third world nations where they may have gotten some old System 34/36 systems shipped in, that will burn up on Jan 1st, but if they're just barely automated, stepping back to non-computerized methods isn't liable to be that much of a problem.

I am a bit less worried about the "people" problem.

• There have been fewer religious "millennial paranoia" movements than I expected (and I was anticipating there to be some. ). Yes, there are crackpots. But they've been remarkably quiet.
• The serious crackpots are going to all load up with guns, and head to a deserted spot in Montana.

  Ed Yourdon says so :-).

  Supposing thousands of crazed lunatics head, heavily armed, to Montana next month. What's likely to happen? They're liable to accidentally shoot each other. This might make next year's Darwin Awards as one of the dumbest things of 1999.

• I agree with Yourdon's assessment that New York City is liable to be a bad place to be on New Year's Eve; if you put vast numbers of partiers wanting to hold "the blowout of the millennium" in one spot, problems are a given.

He has written at least two other books since Rise and Resurrection. He also coauthored another book in the same year.

See http://www.yourdon.com/articles/articlesummary.htm l#Technical books for more details.