There are a few software engineering methods that I find pointless, so I’d like to briefly point them out.

The first is the “Huge-design-up-front”, where an “architect” or even the entire team spend a very long time writing an extremely comprehensive and detailed technical document that specifies in detail how the software will work.

The problem with this approach is that it is a huge waste of time and also it is impossible to design a large project top-down like that. A better way is to involve the entire team in a good design session (a week long at most) while writing some functional specs, diagrams and some other documents, and then to write it incrementally.

A similar fallacy is the “Mountains of documentation fallacy” of having superfluous commenting, “Literate programming” (see the Wikipedia article), etc. The problem with this approach is that the extra documentation is often redundant if the code is well written and factored out ^{[ExtractMethod]}

Some documentation (especially API documentation such as Perl’s POD or Doxygen) is good, and you shouldn’t feel too guilty about writing a comment for an interesting trick, but too much documentation slows things down, and doesn’t help with the design process, and eventually may turn out to be misleading or harmful.

Something else I consider a bad idea is Overengineering or YAGNI (“You Ain’t Gonna Need It”). The basic idea is not to implement too many features at once, or over-complicate the design of the code, and instead focus on getting the necessary functionality working.

YAGNI, put aside, I still believe that some forward-planning is good.

function create_employee(params)
{
    let emp = Employee.new();

    emp.set_birth_year(params[year]);

    emp.set_experience_years(params[exp_amount]);

    emp.set_education(params[education]);

    ### Calculate the salary:
    emp.set_salary(emp.calc_education_factor(emp.get_education()) * emp.get_experience_years());

    ### More stuff snipped.

    return emp;
}