Process Related Classic Mistakes

In my last blog I looked a People Related Classic Mistakes from Rapid Development: Taming Wild Software Schedules by Steve McConnell, which although it’s now been around for at least 10 years, and times have changed, is still as relevant today as when it was written.

As Steve’s book states, classic mistakes are classic mistakes because they’re mistakes that are made so often and by so many people. They have predictably bad results and, when you know them, they stick out like a sore thumb and the idea behind listing them here is that, once you know them, you can spot them and hopefully do something to remedy their effect.

Classic mistakes can be divided in to four types:

  • People Related Mistakes
  • Process Related Mistakes
  • Product Related Mistakes
  • Technology Related Mistakes

Today’s blog takes a quick look at the second of Steve’s categories of mistakes: Process Related Mistakes, which include:

  • Overly Optimistic Schedules 
  • Insufficient Risk Management 
  • Contractor Failure 
  • Insufficient Planning 
  • Abandonment of Planning Under Pressure 
  • Wasted Time During Fuzzy Front End 
  • Short-changed Upstream Activities 
  • Inadequate Design 
  • Shortchanged QA 
  • Insufficient Management Controls 
  • Premature or Overly Frequent Convergence 
  • Omitting Necessary Tasks from Estimates 
  • Planning to Catch Up Later 
  • Code Like Hell Programming 



Overly Optimistic Schedules 

Related to Wishful Thinking. Setting an overly optimistic schedule sets a project up for failure by under-scoping the project, short cutting requirements analysis and testing and failing to appreciate some of the most important development activities. It is a failure to recognise that software takes time to develop. This also has a detrimental affect on staff morale and productivity. 
Insufficient Risk Management 
If you don’t manage risks then only one thing has to go wrong to throw your project in to the gutter. Failure to plan for catastrophe and manage risk is a classic mistake. 
Contractor Failure 
Contractors frequently deliver work that is late, of low quality and fails to meet specifications – despite the fact that they’re frequently used and well paid! Unstable or ill-defined requirements or interfaces are magnified when a contractor is used. Manage the contractor relationship carefully or else contractors can slow a project down rather than speed it up. 
Insufficient Planning
If you don’t plan to produce good software then how can you produce it. 
Abandonment of Planning Under Pressure 
Project teams make plans and then abandon them under pressure – like when they run into schedule trouble. The problem is that plans need to change and adapt. Failing to make new plans and dropping into “Code and Fix” mode is common. 
Wasted Time During Fuzzy Front End 
This is the time normally spent before a project commences, seeking approval and budgeting. Keep this stage short and intense saving your self time that can be used later when the project is under way. 
Shortchanged Upstream Activities
Don’t skimp on activities that don’t directly produce code such as Requirements analysis, architecture and design. Do not “jump into coding”, fixing bugs later in a project is ten times more costly in terms of time than doing it right in the first place.
Inadequate Design
A special case of the above – some people just don’t do design, they go straight into coding. 
Shortchanged QA 
Projects in a hurry often miss out QA. This includes eliminating design, coding reviews, test planning and performing only very basic testing. Short cutting 1 days QA will cost you 3 to 10 days later. 
Insufficient Management Controls 
Controls are needed to provide timely warnings of impeding schedule slips and other problems. Often controls are abandoned when trouble occurs. 
Premature or Overly Frequent Convergence 
Tying together all the various bits of the project to make a product (e.g. documentation, code modules and installation program) either too often or too early in the project life cycle can waste time and effort. 
Omitting Necessary Tasks from Estimates 
People don’t keep records from previous project, they forget about the less visible tasks. These tasks add up. Omitted effort from the original estimate adds up to 20 to 30 percent of a development schedule. 
Planning to Catch Up Later
When late many projects simply plan to catch up later, but they never do. Re-estimated schedules need to reflect slips and lessons learned in building the product. They also need to reflect changes in the requirements specification. If a new function point is added that requires 3 weeks development, then the schedule slips by 3 weeks. 
Code Like Hell Programming 
Or code and fix programming. It is often thought that once a loose requirements specification is defined then well motivated developers can overcome any obstacle using fast loose code as you go techniques.

Reference: Process Related Classic Mistakes from our JCG partner Roger Hughes  at the Captain Debug’s Blog .

Related Articles :

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

Leave a Reply


3 × six =



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close