Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Agree 100%. Just adding:

The "dictating specs to programmers" practice seems to stem from the silly notion of applying manufacturing processes to software development. In the view of companies with this notion, programmers are little more than unskilled translators - the parallel of line workers in manufacturing jargon.

In my experience, one of the worst abusers of this "square peg/round hole" paradigm are internal IT departments.

I read a study in IEEE Computer sometime in the Summer of 2001 or 2002 that showed how bad the application of Waterfall was for software development. Does anyone know of a study on the application of manufacturing processes to software development?



I may be wrong, but I was under the impression that practice stemmed largely from older days, when "programmers" were people who translated specifications into machine code or assembly, and programs were actually written and specified by higher ups--essentially, the day that programmers were more like human compilers than what programmers do today.


I can't speak to early computing, but starting around when business applications emerged (60's/early 70's?), developers were very involved in gathering requirements, designing, coding, testing, etc. Shortly after I entered the field, circa 1992, I started hearing about software development as an assembly line process. The developer role started being split: BA, architect, coder, sometimes a QA staff, etc. Whenever I've worked on projects with teams split out this way, it becomes a nightmare of communication overhead and miscommunicated requirements.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: