Edward YourdonResenhas

Can't rate it as I read this book very long time ago. But I remember it been mildly entertainig and mostly unpractical. There is too much cultural difference.

When I discovered object-oriented software development in the 1990s, it changed the way I designed and build programs, and especially how I thought about software, changed it for the better. This was mostly through Peter Coad's books and blog.

I could only wish there had been such methods in the air when I started programming a decade or two earlier.

Coad's, methods seemed over-simple, but they were not. They were, more than most techniques in those days, based on first analyzing what had to be done, thinking about what the expected users would need, more than what the developers wanted to do.

I kept his books on analysis (OOA), design (OOD), programming (OOP), and others, for a long time.

013901702X

135986249

Tedious and repetitive, no useful info.

Wished I'd written this book, just up my way of thinking about PM. Am I therefore biased in my score?

If you are working at a place that believes in the Death March, you owe it to yourself to find time to read this book (not an easy thing when you are working 14 hours a day, seven days a week).

If you have never worked at such a place, you should at least skim the book to understand why you don't want to work for such an employee.

If you've survived a death march and now work at a saner company, you don't need this book in the least.

Word of warning: it is depressing to read this book and then see your employer is a textbook example of how not to run a software company.

Knowing what would happen, I scheduled a meeting with my manager and brought in the book with little sticky-notes on key pages. I then cataloged what the company was doing wrong and why it was bad.

They fired me, of course. In a month I was working for a fantastic start-up. I've been at that firm for five years now. We work hard, but we do not do death marches.

That other company? Dead and gone.½

do you remember a time when we were all afraid of the Y2K bug? I do. The question is did we fix EVERYTHING in time or was it never any big deal after all? It seemed like a good idea at the time--and it still has some good emergency prep ideas (or so we justify)

Isn't Yourdon the one who decided that the world was going to crash in 2000 due to the much overhyped Y2K bug? Let that be your guide.

Isn't Yourdon the one who decided that the world was going to crash in 2000 due to the much overhyped Y2K bug? Let that be your guide.

Книга Эдварда Йордона "Путь камикадзе" представляет собой полное руководство по выживанию в безнадежных проектах, предназначенное для разработчиков программного обеспечения. Практически каждому разработчику ПО и менеджеру приходится сталкиваться с проектами, характеризующимися никуда не годными персоналом, планом и бюджетом, т.е. проектами, обреченными на неудачу. В условиях реинжиниринга корпораций безнадежные проекты становятся "стилем жизни" многих организаций. Книга Эдварда Йордона является руководством по решению следующих проблем: выживание в проектах, обреченных на неудачу; достижение оптимальных соглашений во время переговоров; управление персоналом и расстановка приоритетов; выбор средств и технологий; определение момента, когда уже пора выйти изпроекта. Эдвард Йордон применяет свою уникальную технологию и интуицию менеджера к наихудшим вариантам софтверных проектов, показывая, как максимально повысить шансы на успех, или, по крайней мере, вывести вашу карьеру из-под удара. Шаг за шагом Йордон проходит все стадии жизненного цикла проекта, учит менеджеров и разработчиков правильно вести себя с заказчиками и оптимально использовать доступные ресурсы, включая людей, средства, процессы и технологию. Учитесь проявлять необходимую гибкость при проведении переговоров, расставлять осмысленные приоритеты и… вовремя выходить из проекта. Если вам когда-либо требовалось совершить невозможное, "Путь камикадзе" - ваша книга.

I remember waiting to see what would happen. And then nothing did. Or did it?

This is about how to survive a software development project when management has not allocated sufficient resources (e.g. time, money, people) to complete the job. Like Peoleware, it's often oriented at the human side of things.

Not Read

Not Read