SENG411L2 Notes
From Craig
| Table of contents |
Death Marches Revealed
"Every single project I've ever worked on was a Death March" -- Craig Schock
"Corporate insanity is doing the same thing over and over again, and each time expecting different results" -- Richard Sargent (as quoted in "Death March")
"Death march projects are rarely billed as such, and it takes a lot of work when being hired from the outside to discover if your hiring company is prone to creating Death March projects". -- Dave Kleist (as quoted in "Death March")
Basic Definition
- A death march project is one whose "project parameters" exceed the norm by at least 50% through:
- Schedule compression
- Staff compression
- Budget compression
- Functionality inflation
Often, the whole system can be made worse by employing a combination of the above.
A death march project is one for which an unbiased, objective risk assessment (which includes an assessment of technical risks, personnel risks, legal risks, political risks, etc.) determines that the likelihood of failure is greater than or equal to 50%.
There are different kinds of death marches. One of the most important distinguishing characteristics is size:
- Small scale: 3-6 people, 3-6 months
- Medium scale: 20-30 people, 1-2 years
- Large scale: 100-300 people, 3-5 years
- Mind-boggling: 1000-2000 people, 7-10 years
Why do death marches happen?
- Politics, Politics, Politics
- Naive promises made by marketing, senior execs, project managers, etc
- Naive optimism of youth: "We can do it over the weekend"
- The "startup" mentality
- The "Marine Corps" mentality. Real programmers don't need sleep
- Intense competition caused by the globalisation of markets
- Intense competition caused by the appearance of new technologies
- Intense pressure caused by government regulations
- Unexpected and/or unplanned crises. Bankruptcies, project turnover, etc.
- Short term thinking
Why on earth would anyone participate in such a project?
- It is the norm
- The risks are high, but so are the rewards
- Stock options
- The "Mt. Everest" syndrome
- The "buzz" of working intensely with other committed people
- Naive optimism of youth
- Unemployment
- It's required for future advancement (earning your spurs)
- Bankruptcy or worse
- Escape from the normal mundane kind of work
- Revenge
General Software Engineering
"Programming" and "Application Development" are 2 very different things
- Programming is easy
- Developing applications is hard hard work!
Application development is at least an order of magnitude more complex than programming
- Generalization
- Testing
- Documentation
- Maintenance
- Integration
- Interfaces
There are a great many aspects of programming which are fun:
- Creativity, joy of making things
- Pleasure in making things which are useful to other people
- Fascination with complex puzzle-like problems
- Joy of always learning something new
- Creativity using a very flexible medium.
Programming then is fun because it gratifies creative longings built deep within us and delights sensibilities we have in common with all [people]
-- Frederick Brooks, The Mythical Man-Month
The woes of application development
- Overhead
- Grunt work, tedious work
- Responsibility by no authority
- Dependence on others
- Product obsolescence
Building software is inherently hard work. Complexity is king
Essential Difficulties
- Complexity
- Changeability
- Invisibility (difficult to visualize)
Silver Bullets
- Ada and other high-level languages
- Object-oriented programming
- Artificial Intelligence
- Expert Systems
- "Automatic" Programming
- Graphical Programming
- Program Verification
- Environments and Tools
- Workstations
Promising Improvements in the field of SE
- Buy vs. Build
- Requirements refinement and rapid prototyping
- Incremental development
- Great Designers
