Adding more personnel to a project is not going to help.
Executives who are incompetent or lack a technical background frequently believe that adding extra warm people to a project can speed things up. It is a novice move that always makes the dev team sigh.
Having more people slows things down, rather than speeding them up. An experienced member of the team will have to drop everything to bring the person up to full speed on the team’s progress.
If that individual is a recruit or a newcomer, the situation is exacerbated because everything this newcomer does must be double-checked by other veterans, which takes time away from the real task.
You cannot simply “throw something in.”
“Can they just put in [insert feature]?” is one of the most harmful phrases a stakeholder can utter. Stakeholders and users are not programmers, so they have no idea if their insignificant request is even conceivable, let alone how tough it would be to implement in a way that does not disrupt the rest of the project.
The difficulty is that administrators are vulnerable to pressure from stakeholders and tend to accept requests without question, commit the team to that which takes significantly longer than the management originally estimated, putting more strain on the team, and leading to more blunders.
Nobody is happy at the end of the day.
QA will not be able to catch every flaw.
Supervisors (especially non-technical ones) appear to believe that any code that passes QA should be spotless and sanitized.
There will be no bugs!
That is, without a doubt, the goal. Each day, QA spends hours upon hours sifting through the code and testing different functionalities and use cases for flaws to fix.
Complex software applications, on the other hand, are difficult to test as there are so many variables to consider. The act of simply adding a file might become a QA hurdle. How many diverse types of files have you tried? What size are they? What is the length of the file names?
Each of these aspects has the potential to cause a defect, and the possibilities grow when one piece of software interacts with another (e.g. emailing an attachment after uploading it). Testing all variables is challenging for QA.
Another characteristic of bugs is that they do not behave logically. Some flaws can only be triggered in the most unusual and unusual circumstances (for example, a program will crash if you hit the “Like” button 52 times). QA cannot account for every scenario or condition.
It is always a pain to work with other people’s code.
Working on a computer program is different from operating a car engine. Individual corporations, divisions, teams, and even — especially — individual developers all have different code.
Working with other people’s code is akin to going through a minefield. You have no idea how the code is put together, how one area interacts with another, or whether a change may backfire and bring the entire program down with it.
Effort and production are not synonymous.
Many executives appear to believe that if you spend more time on something, it must be progressing. While this is accurate all the time, there seem to be times when the contrary is true.
Return to our earlier point about dealing with other people’s code for an illustration. You will spend most of your time reading it and struggling to figure out just what to accomplish. You will not be confident enough to update it without destroying anything until much (much) later.
Technical debt exists, and it will eventually catch up to you.
When given the option of doing something well or doing something quickly, most employers will select the latter. The product is still functional, and the boss appears to have used “management skills” to push the product to market.
Except that this quick-and-dirty fix will certainly lead to more serious issues on the road. Sloppily written code always leads to difficulties that jeopardize future efforts.
Contact Seattle Software Developers to discuss you next software project or mobile app!
