February 2009
Beginner
222 pages
5h 23m
English
Content preview from 97 Things Every Software Architect Should Know
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.
Chapter 21. Avoid Scheduling Failures
Norman Carnovale is an IT architect working for Lockheed Martin Professional Services on Homeland Security-related projects. He was formerly a software consultant, instructor, and architect for Davalen, LLC (http://www.davalen.com), a Premier IBM Business Partner specializing in WebSphere Portlet Factory, WebSphere Portal, and Lotus Domino projects.
—Norman Carnovale
FAILED PROJECTS CAN HAPPEN FOR A MULTITUDE OF REASONS. One of the most common sources of failure is altering the project schedule in midstream without proper planning. This kind of failure is avoidable, but it can require major effort on the part of multiple people. Adjusting the timeline or increasing resources on a project are not normally of concern. Problems start when you are asked to do more in the same timeline or when the schedule is shortened without reducing the workload.
The idea that schedules can be shortened in order to reduce cost or speed up delivery is a very common misconception. You'll commonly see attempts to require overtime or sacrifice "less important scheduled tasks" (like unit testing) as a way to reduce delivery dates, or increase functionality while keeping the delivery dates as is. Avoid this scenario at all costs. Remind those requesting the changes of the following facts:
A rushed design schedule leads to poor design, bad documentation, and probable quality ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access
More than 5,000 organizations count on O’Reilly
O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.Julian F.
I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.Addison B.
I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.Amir M.
I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.