The fact that code written in during crunch mode is usually much more bug-ridden than code that is not is exacerbated by the fact that such code is usually put through much less rigorous testing procedures - usually due to lack of motivation and time. Such errors often involve complex interactions of a large number of individually complex components and can take days, if not weeks, to find and fix. Errors - or bugs - in code are often not discovered until much later in a project when this code happens to be tested in new ways.
#MODO SOFTWARE COMPARISON FULL#
Such code is often lacking in documentation, nearly unreadable (even by its creator), and full of errors. Code that is written during extreme fatigue and stress is by all accounts almost always of much lower quality than code written in more relaxed conditions. While software developers don't have to worry about losing fingers or falling off of ten-story buildings when they make mistakes, they do have to worry about making the future work of themselves and their co-workers extremely difficult. Mistakes in programming can also take a very long time to fix much longer, in fact, than they usually take to make. Thus, programming is very much vulnerable to the toll that sleep deprivation and stress take on workers. Programming is not something that can be started at the drop of a hat or done while engaging in casual conversation: programmers often take up to an hour to "warm up" at the start of each day, and they often desire solitude for extended periods of time to engage in their work. Programming requires intense concentrationįirst of all, the main activity of software development - programming - often, if not usually, requires intense concentration and mental exertion. There are a number of attributes specific to software development (and related fields) that have led us to hold this view. In fact, it may even be the case that software development is more susceptible to the detrimental effects of overwork than many other fields. We believe that there is no reason to think that studies linking extended overtime to decreased total output should not also apply to software development. Towards the end of the week, any problem that he "solves" quickly usually requires at least a day or more to re-fix later on.Ī large number of other postings to this discussion support similar conclusions. He's in at 6:30am and usually leaves around 6:30 or 7:00pm and he NEVER takes lunch breaks. The lead programmer on my current project works at least 60 hours every week (and has for years) and more than that about half of the time. We missed obvious architectural improvements that could have saved us days of work.
We always ended up making bad mistakes that took a lot of time to clean up. The people I know who think they can do it can't do it either. One poster, jarich, says the following about working continual 60 to 80 hour weeks:
In a recent Slashdot discussion entitled "Can People Really Program 80+ Hours a Week," the general consensus among most posters seems to be that programming productivity does in fact become negative after a certain number of hours worked. Although to our knowledge no in-depth research has been done to discover the relationship between productivity and hours worked in software development, substantial anecdotal evidence suggests that the results found in other fields are also valid in this one.
0 kommentar(er)
