Everyone has their myths that they believe when it comes to software development. Here we look at some of these myths and determine what are some of the best/worst of them. (And yes, I’ve actually heard people say most of these, and then some.)
Management Myths
These are myths that managers believe and tell people:
We have a book of standards:
- Is it up to date?
- Is it being used?
- Is it effective for what you are doing?
If we get behind schedule, we can just add people:
- Where will these people come from?
- Are they properly trained?
- Who will get them up to speed on the project? (It can take weeks to months to get up to speed.)
I can decide to outsource and let a third party handle it for $5/hr because they are in ____________, and they can manage it for me:
- If you can’t manage something internally with people you see every day, you won’t be able to manage a third party
- The quality you get may not be as good as you hoped for – Ask Boeing with their 737 Max
Customer Myths
A General statement of objectives is enough to start with, we can fill in details later:
- While comprehensive list is not always possible, purposefully ambiguous is just foolish.
- Changes down the line may require major rewrites putting your schedule in jeopardy
- Adding “just one more thing” is a never ending process – scope creep which can derail any schedule.
Software requirements always change. But change is easily accommodated because software is flexible.
- The impact of the change is often tied to when the change is requested
- Changes can have a direct correlation to cost
Practitioner’s Myths
Once we write the program, our job is done!
- Ha!!!!
- Updates to hardware or systems might require changes
- Users will ask for revisions
- Sometimes you will find errors much later on
- It is estimated that 60-80% of the time spent on a project is after it is delivered.
Until it is running, we have no idea how to assess the quality.
- Technical reviews can help us identify issues early one.
- Various forms of testing (unit, integration, data) can help find issues and determine quality.
Software engineering will take too much time:
- SE is not about paperwork, it’s about quality. And quality products require less upkeep and work time to build.
Software Development Myths was originally found on Access 2 Learn
